AD-moo  S19  AIR  FOKCe  INST  Of  TECH  MIShT-PATTERSON  aFI  oh  SCHOO— etc  F/s  9/j 

CONSTRUCTION  OF  A  SENCRAL  FURPOSE  CONNANO  LANRUARE  FOR  USE  IN  C--€TCnM 
SCP  80  HO  881CSS 

UNCLASSIFIED  AFIT/8CS/Ee/80S-lS  m 


Accession  For 

NTIS  GRA&I 
DTIC  TAB 

Unannounced  i’^ 

Juntificr.tion _ 

By— _  _ 

Disirlbut icn/ 
AvailabU  ity  , 

Av."  i  i  ,■  n.; / or 
l-’t  ^P'-CUli 


CONSTRUCTION  OF  A  gENERAL  PURPOSE 


COMMAND  LANGUAGE  FOR  USE  IK 


COMPUTER  TO  COMPUTER  DIALOG 


THESIS  • 

)  ' 

/  ,  AFIT/GCS/EE/80S-15  Wayne  D. 'Griess 

Captain  USAF 


DTIC 

ELECTE 


JUL  1  1981 


Approved  for  public  release;  distribution  unlimited, 


AFIT/GCS/EE/80S- 15 


I 


CONSTRUCTION  OF  A  GENERAL  PURPOSE 
COMMAND  LANGUAGE  FOR  USE  IN 
COMPUTER  TO  COMPUTER  DIALOG 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 

in  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science 


by 

Wayne  D.  Griess,  B.S. 
Captain  USAF 

Graduate  Computer  Systems 
September  1980 


» 


Approved  for  public  release;  distribution  unlimited. 


Preface 
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facility.  To  expand  the  processing  capability  of  the  new 
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computer  system  was  desired.  I  undertook  this  project  and 
constructed  a  general  purpose  command  language  that  could  be 
used  in  varied  applications. 
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Colonel  James  Rutledge  and  Professor  Gary  Lament  for  their 
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His  experience  and  knowledge  of  the  NOVA/ECLIPSE  computers  were 
eagerly  exploited.  Finally,  I  thank  my  wife  Betty  and  my  two 
children  for  their  patience,  sacrifice,  and  love.  They  have 
been  a  source  of  strength  and  sustenance  throughout  this 
project.  I  also  reverently  give  thanks  and  praise  to  my  Lord 
and  Savior  Jesus  Christ  for  His  providence  and  counsel  through 
it  all. 
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Abstract 

Two  computer  programs  were  developed  and  implemented  to 
enable  intercommunication  between  a  Data  General  NOVA/ECLIPSE 
computer  system  and  another  modem  linked  computer  system.  One 
program,  called  TTERMOP,  allows  a  user  to  sit  at  a  NOVA 
terminal  and  interact  with  a  connected  system  in  a  transparent 
mode.  The  other  program,  called  MONITOR,  is  a  command  language 
interpreter  that  examines  and  executes  instructions  contained 
within  an  action  file.  An  action  file,  consisting  of 
instruction  strings  and  associated  control  parameters,  is 
designed  to  be  dependent  upon  a  connected  system  with  regard  to 
contents,  yet  independent  of  such  a  connected  system  with  regard 
to  structure  and  format.  The  interpreter  is  written  in  FORTRAN 
IV  with  FORTRAN  and  assembly  language  modules.  Actual 
implementation  of  the  programs  is  accomplished  between  the 
NOVA/ECLIPSE  and  the  Aeronautical  Systems  Division  Control  Data 
CYBER  computer  system.  ASCII  data  files  between  20  and  35,000 
bytes  have  been  transferred  between  the  two  interconnected 
systems,  each  transfer  initiated  by  a  single  string  command 
acceptable  to  the  interpreter  and  compatible  with  a  tailored 
action  file  for  the  CYBER  system.  The  programs  were  designed  to 
be  flexible  enough  for  use  with  several  different  connected 
systems,  and  general  enough  to  be  hosted  on  a  system  other  than 
the  NOVA/ ECLIPSE .  However,  no  attempt  is  made  to  implement  the 
programs  outside  of  the  NOVA/ECLIPSE  -  CYBER  environment. 
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CONSTRUCTION  OF  A  GENERAL  PURPOSE  COMMAND  LANGUAGE 
FOR  USE  IN  COMPUTER  TO  COMPUTER  DIALOG 


I .  Introduc  t ion 


Backnround 

Under  sponsorship  of  the  United  States  Air  Force  Electronic 
Systems  Division  and  the  United  States  Air  Force  Aerospace 
Medical  Research  Laboratory,  the  Air  Force  Institute  of 
Technology  (AFIT)  Electrical  Engineering  (EE)  department  is 
undertaking  research  in  digital  signal  processing,  specifically 
digital  speech  processing  and  digital  image  processing.  A  Data 
General  Corporation  (DGC)  NOVA  2/10  computer,  a  DGC  ECLIPSE 
S/250  computer,  and  associated  peripheral  equipment  are  being 
combined  and  integrated  to  form  the  signal  processing  facility. 

To  expand  the  local  processing  capability  of  the  facility, 
the  EE  department  proposed  to  interface  the  DGC  computers  with 
the  larger  and  more  sophisticated  Control  Data  Corporation  (CDC) 
CYBER  computer  system,  which  is  operated  by  the  United  States 
Air  Force  Aeronautical  Systems  Division  (ASD)  and  which  provides 
support  to  AFIT.  (Both  AFIT  and  ASD  are  located  at 
Wr ight-Patter son  AFB,  Ohio.)  Interfacing  the  two  systems  would 
allow  intercommunication  between  the  two  systems,  wherein  the 
advantage  of  each  system's  features  could  be  utilized.  The  CDC 
CYBER  system,  consisting  of  a  dual  CYBER  175  and  a  CYBER  750, 
could  readily  provide  the  "number  crunching"  and  file  repository 
required  to  help  analyze  signals.  The  NOVA/ECLIPSE  system  could 
then  be  devoted  to  other  signal  processing  functions,  such  as 


analog  to  digital/digital  to  analog  conversions.  Furthermore, 
though  the  systems  would  be  capable  of  intercommunication,  the 
failure  of  one  of  the  two  systems  would  not  mean  the  failure  of 
the  other  system.  Thus,  each  system  could  stand  alone  —  or  be 
interconnected  for  supplementary  processing  power. 

Expanding  the  capability  of  the  signal  processing  facility 
by  interconnection  to  the  CYBER  computer  system  may  not  be  the 


only  expansion  possible. 

Many  other 

computer  facilities 

are 

available 

in  the  AFIT 

School  of 

Engineering,  as  well 

as 

throughout 

Wr  ight-Patter 

son  AFB. 

The  EE  department 

also 

proposed,  therefore,  that  the  method  of  interfacing  the  local 
NOVA/ECLIPSE  computers  be  flexible  enough  to  be  used  with 
systems  other  than  the  CYBER,  and  that  the  interfacing  be 
general  enough  to  be  applied  by  separate  and  distinct  systems, 
if  possible. 

Problem  Statement 

Interfacing  the  NOVA/ECLIPSE  computers  to  the  CYBER  system 
or  any  other  system  may  be  viewed  in  two  parts.  One  part  of  the 
interfacing  would  be  to  connect  the  MOVA/ECLIPSE  computers  to 
the  CYBER  system  just  as  any  other  peripheral  would  be  connected 
or  appear  to  be  connected.  In  this  case,  the  CYBER  system  would 
treat  the  NOVA/ECLIPSE  computers  as  one  of  its  many  terminals, 
not  recognizing  that  it  is  a  complete  computer  system.  This 
type  of  interface  is  not  complex,  and  involves  accessing  an 
input  and  output  port  on  the  NOVA  or  ECLIPSE  via  a  data  line  of 
the  local  telephone  system  to  the  CYBER  system.  Connection  to 


the  CYBER  syEtem  would  be  accomplished  in  the  same  fashion  as 
other  terminals  are  connected,  A  user  would  call  a  prescribed 
telephone  number  and  couple  the  telephone  line  to  the  data  rt 
line  via  a  standard  modem.  After  connection,  a  resident 
software  program  designed  for  the  purpose  would  bo  called  into 
execution  to  control  input  and  output  transfers.  Any  local 
terminal  of  the  NOVA  or  ECLIPSE,  whichever  owned  the  selected 
data  port,  would  appear  transparently  as  a  terminal  directly 
connected  to  the  CYBER. 

The  limitations  of  this  first  part  are  the  same  as  those 
limitations  any  typical  terminal  has  when  connected  to  the  CYBER 
system.  First  of  all,  the  language  for  communication  must  be 
that  of  the  "host"  system,  and  in  this  instance,  it  is  the  CYBER 
operating  system.  Presently,  the  CYBER  operating  system 
language  is  called  NOS/BE  (Network  Operating  System/Batch 
Environment).  The  users  of  the  signal  processing  facility 
desire  a  language  of  intercommunication  other  than  NOS/BE,  that 
simplifies  intercommunication  and  reduces  the  complexity  of  user 
access.  Furthermore,  they  desire  that  such  a  language  be 
understandable  and  portable,  i.e.,  that  may  be  used  on  more 
than  one  machine  for  the  same  purpose.  A  second  and  even 
greater  limitation  of  the  transparent  terminal  interface  is  that 
no  direct  computer  to  computer  dialog  may  take  place.  Under  a 
transparent  terminal  operation,  users  may  access  files  of  the 
CYBER  or  connected  system,  but  cannot  access  local  files.  Also, 
there  is  no  provision  for  the  direct  exchange  of  information, 
such  as  file  transfers,  in  the  transparent  mode. 
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A  second  part  of  interfacing,  then,  would  be  to  connect  the 
NOVA/ECLIPSE  computers  to  the  CYBER  system  or  any  other  system 
such  that  direct  information  exchanges  are  possible.  Within 
this  type  of  environment,  a  user  would  have  access  to  files  on 
the  nova/eclipse  and  the  connected  computer  system.  For 
example,  files  from  the  local  system  could  be  transferred  to 
the  connected  system,  executed,  and  returned.  This  type  of 
interfacing  is  significantly  more  complex,  even  though  basic 
connection  techniques  remain  the  same,  since  files  must  be 
identified  and  manipulated.  Because  of  this  need  to  manipulate 
files,  the  software  program  to  control  information  transfers 
becomes  much  more  complex  particularly;  and,  hence,  requires  the 
greater  concentration  of  design  and  development  efforts.  Just 
as  in  the  case  of  the  transparent  mode,  the  users  of  the  signal 
processing  facility  desire  a  language  of  intercommunication  that 
is  understandable  and  portable.  The  language  must  be  simple  and 
provide  a  means  to  issue  commands  both  to  the  local  NOVA/ECLIPSE 
system  and  the  connected  computer  system,  such  as  the  CYBER. 

The  problem,  then,  is  to  develop  a  method  of 
intercommunication  for  use  in  computer  to  computer  dialog.  In 
its  narrower  focus,  the  problem  becomes  one  of  developing  a 
command  language  on  the  DGC  NOVA/ECLIPSE  computer  system  for 
intercommunication  with  the  CDC  CYBER  computer  system. 
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Scope 

An  examination  of  this  problem  involves  researching 
computer  to  computer  interconnections,  with  particular  emphasis 
upon  software  development.  The  compatabil ity  of  operating 
systems  is  briefly  considered,  with  respect  to  the  degree  of 
interconnection  required  at  the  software  level.  The  scope  of 
the  study  also  includes  the  guidelines  that  surround  computer 
to  computer  dialog,  humanized  input  and  output,  and  man-machine 
interfaces.  Though  hardware  considerations  in  the  actual 
implementation  will  be  considered,  the  study  is  not  oriented 
toward  hardware,  nor  will  hardware  be  examined  in  any  depth. 
Further,  the  study  will  not  specifically  be  concerned  with  the 
actual  digital  signal  processing  capabilities  of  the  computer 
system.  Although  the  topics  above  will  be  considered,  the 
study  will  be  devoted  almost  exclusively  to  the  analysis, 
design,  development,  implementation,  testing,  and  review  of 
software  for  interfacing  the  NOVA/ECLIPSE  computers  to  a 
connected  computer  system  (specifically  the  CDC  CYBER)  via  a 
defined  command  language. 

General  Approach  and  Pr e 1 iminarv  Results 

The  first  step  in  constructing  a  command  language  for  use 
on  the  nova/eclipse  computers  was  to  search  the  literature  for 
ideas  and  projects  of  a  similar  nature.  Few  articles  were  found 
that  directly  impacted  upon  the  project  at  hand,  but  methods  and 
parameters  for  interfacing  systems  in  general  were  investigated. 
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Other  thesis  efforts  were  reviewed  for  applicability  to  this 
effort,  and  possible  expansion  (Ref  4  and  8).  The  literature 
investigation  was  followed  by  a  period  of  machine 
familiarization,  both  of  the  NOVA/ECLIPSE  and  the  CYBER.  As  the 
NOVA/ECLIPSE  computer  system  was  installed  just  prior  to  the 
full  scale  thesis  effort,  much  time  was  spent  learning  the 
characteristics  of  the  NOVA/ECLIPSE  Real-Time  Disk  Operating 
System  (RDOS).  Initially,  programs  taken  from  operating 
manuals  were  copied  and  executed-  Later,  original  programs  were 
developed  to  duplicate  the  same  actions.  These  initial  efforts 
concentrated  on  assembly  language  facilities,  as  these  were  the 
least  familiar.  The  CYBER  had  been  used  before  and  was  not 
unfamiliar.  Nonetheless,  operating  system  characteristics  were 
examined  in  more  depth. 

Design  of  the  software  to  implement  a  transparent  terminal 
operation  was  next.  It  is  at  this  point  that  the  details  of 
interrupts  and  their  operation  were  examined  and  tested  in 
experiments.  Once  the  transparent  mode  v;as  workable  from  a 
local  terminal  to  another  local  terminal,  efforts  turned  to 
developing  the  actual  command  language.  Using  top-down  design 
techniques  and  successive  refinement,  individual  modules  were 
developed  as  needed  to  implement  parts  of  the  language.  Early 
on,  the  project  was  divided  into  two  parts,  the  output  from  the 
NOVA/ECLIPSE  and  the  input  to  the  NOVA/ ECLIPSE .  Multitasking 
was  used  to  allow  asynchronous  operation  of  these  two  parts.  A 
further  division  was  made  to  the  design.  An  action  file  was 
created  to  actually  contain  command  sequences  as  needed  by  the 
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user.  The  main  program  became  an  interpreter  to  examine  and  act 
upon  this  action  file.  Once  a  working  subset  of  the  final 
product  was  available,  access  to  the  CYBER  system  was  tried. 
The  transparent  mode  software  required  minor  modifications  and 
transitioned  well  to  on-line  execution.  The  transition  of  the 
command  language  itself  was  more  painstaking  and  slow. 

Eventually  the  modules  were  all  developed  and  combined, 
and  then  several  tests  and  trials  were  conducted.  Once  the 
program  was  in  a  reasonably  workable  state,  efforts  began  to 
more  fully  and  comprehensively  document  design,  development, 
implementation,  and  validation  findings.  Finally,  the  project 
was  put  into  written  form  and  a  user's  manual  was  written  to 
instruct  users  in  the  use  of  the  command  language.  Follow-on 
steps  to  this  process  are  recommended  in  the  Conclusion,  Chapter 
V. 

Sequence  of  Presentation 

The  introduction  to  this  project  is  followed  by  an  analysis 
of  the  literature  regarding  man-machine  interfaces  and  command 
language  structures,  an  analysis  of  the  computer  systems 
involved,  the  transparent  terminal  operation  mode,  and  the 
command  language  itself.  The  analyses  are  followed  by  an 
explanation  of  the  development  theo. /  behind  the  software 
programs.  Once  the  theory  has  been  presented,  the  actual 
development  of  the  software  will  be  discussed,  concentrating 
first  on  a  program  called  TTERMOP  —  the  transparent  terminal 
operation  mode  software,  and  then  a  program  called  MONITOR  — 
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the  actual  command  language  mode  software.  The  discussion  of 
MONITOR  will  include  a  look  at  various  subordinate  modules  and 
routines  that  comprise  MONITOR.  A  section  regarding  validation 
of  the  software  will  follow  the  software  development 
description,  including  its  current  state  and  usefulness.  The 
project  will  then  be  summarized,  pointing  out  several 
possibilities  for  follow-on  work  to  this  thesis. 
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II. 


Detail pd  Analysis 


An  analysis  of  the  problem  of  interconnecting  the 
NOVA/ECLIPSE  computers  to  another  computer  system  begins  with  a 


look  at  interfacing  in 

general . 

Several 

elements  of 

the 

literature  are  examined 

with  respect 

to 

the 

concepts 

of 

man-machine  interfaces. 

computer 

to 

computer 

dialog. 

and 

command  languages.  This  introductory  look  at  the  problem  is 
followed  by  an  introduction  to  the  NOVA/ECLIPSE  computers  and 
their  primary  features.  Once  the  computers  have  been  described, 
a  closer  look  at  the  methods  of  interfacing  for  the  NOVA/ECLIPSE 
are  mentioned,  particularly  with  regard  to  the  modes  of 
operation  envisioned. 

Man-Machine  Interface 

It  is  becomming  increasingly  important,  though  it  has 
always  been  important,  that  there  be  a  proper  perspective  rfith 
regard  to  the  interaction  of  people  with  computers.  The  past 
emphasis  seems  to  have  been  on  the  usage  of  computers;  the 
newer  emphasis  is  on  the  usage  of  people  (Ref  5:4).  This  change 
in  emphasis  is  an  outgrowth  of  the  volumes  of  information 
computers  generate  and  the  ever  wider  proliferation  of 
computers.  How  do,  or  how  should,  the  two  cooperate?  James 
Martin  states: 

This  difference  in  thinking  talent  —  the  computer 
being  good  for  altrafast  sequential  logic  and  the 
human  being  capable  of  slow  but  highly  parallel  and 
f  associative  thinking  —  is  the  basis  for  cooperation 

i  between  man  and  machine  (Ref  5:7). 
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The  logical  ansv;cr  to  cooperation,  then,  lies  in  utilizing 
both  people  and  computers  in  a  manner  consistent  with  their 
strengths.  It  is  obvious,  therefore,  that  people  should  not  be 
called  upon  to  do  the  kind  of  work  that  a  computer  can  do 
better.  It  should  be  equally  obvious,  as  well,  that  computers 
should  not  be  called  upon  to  be  substitute  people.  The  future 
will  undoubtedly  lead  to  ever  greater  computer  maturity,  to  the 
point  where  some  human  functions  can  be  paralleled  or 
duplicated.  The  present,  however,  would  seemingly  be  better 
served  if  people  and  computers,  each  with  their  relatively 
mutually  exclusive  spheres  of  advantage,  were  deliberately  and 
constructively  meshed  together. 

With  this  view  in  mind,  human  beings  could  more  profitably 
gain  from  computers  if  computers  were  creatively  linked  to 
enhance  their  speed,  throughput,  and  intercommunication.  And, 
such  computer  systems  would  better  profit  people  who  use  them, 
if  their  output  and  input  facilities  were  readily  understood, 
easily  manipulated,  functionally  controlable,  and  consumer 
dependent.  The  point  where  interaction  culminates  in 
identifying  the  most  effective  techniques  for  enabling  a  user  to 
access  needed  data  quickly,  easily,  and  in  a  relatively  natural 
manner,  is  the  user-computer  system  interface,  called  the 
man-machine  interface  (Ref  3:1-1). 
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Computer  to  Computer  Interface 

Linking  computers  together  is  an  action  to  improve  upon  the 
individual  computer's  capability  and  to  provide  a  more  powerful 
resource  for  users.  Just  as  input  and  output  data  is  a  dominant 
factor  in  the  application  of  single  computers  (Ref  10:119),  so 
it  is  with  multiple  computer  systems.  It  should  not  be 
surprising,  therefore,  that  intercomputer  or  interprocessor 
communication  is  primarily  at  the  data  level  (Ref  12:67). 

Interfacing,  or  linking  computers  together,  is  widely 
discussed  throughout  the  computer  literature.  Many  types  of 
interfacing  are  possible,  and  many  terms  are  used  to  describe 
differing  methods  and  degrees  of  interface.  An  article  in 
Comput ina  Surveys  presented  a  naming  scheme  or  taxonomy  for 
identifying  various  systems  of  interconnected  computers  (Ref 
2:197-213).  The  scheme  was  presented  as  a  tree  diagram  of  four 
levels,  wherein  the  two  highest  levels  were  concerned  with 
strategic  (policy)  issues  and  the  two  lower  levels  were 
concerned  with  tactical  (implementation)  issues.  The  authors 
defined  two  terms  of  interest  with  regard  to  communication 
interconnection.  The  first  term,  path,  is  a  medium  by  which  a 
message  is  transferred  between  the  other  system  elements,  such 
as  wires  or  buses.  The  other  term  was  switching  element,  an 
"intervening  intelligence"  between  the  sender  and  receiver  of  a 
message.  The  switching  element  affects  the  destination  of  the 
message  in  some  way. 
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Within  this  scheme,  communication  interconnection  is  either 
direct  or  indirect.  A  transfer  path  can  be  either  dedicated  or 
shared,  and  a  variety  of  system  ar chitechures  may  be  employed  to 
interconnect  computers.  As  an  example,  a  multiprocessor  system 
is  described  as  direct,  having  no  need  for  a  transfer  control 
method,  and  using  a  shared  path  transfer  structure  with  a 
central  memory  system  ar chitechure .  As  another  example,  an 
irregular  network  system  architecture  follows  from  an  indirect 
communication  interconnection,  decentralized  routing,  and  a 
shared  transfer  structure.  In  the  authors'  scheme,  the  variety 
of  interconnections  may  range  from  a  complete,  dedicated 
interconnection  to  an  indirectly,  decentralized,  shared  path 
window.  Nonetheless,  the  common  element  used  to  describe  all  is 
the  data  level  communications  path. 

In  any  interconnected  computer  system,  a  protocol  is 
necessary.  "A  protocol  is  essentially  a  set  of  conventions 
between  communicating  processes  on  the  format  and  content  of 
messages  to  be  exchanged  (Ref  1:4-3)."  The  protocol  can  be 
easily  determined  in  some  computer  links  by  simply  adapting  the 
internal  protocol  of  one  of  the  individual  computers. 

In  all  cases,  computers  are  interconnected  to  benefit  the 
users.  The  better  and  clearer  the  interconnection  of  computers, 
the  less  likely  the  confusion  between  man  and  machine. 
Further,  the  more  likely  will  be  the  usefulness  of  the  system 
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level  and  is  the  starting  point  for  future  interconnection 
efforts. 

Command  Language  Interfacing 

The  problem  of  interfacing  the  NOVA/ECLIPSE  computers  with 
other  computer  systems  is  one  of  command  language  interfacing, 
in  which  the  goal  is  tc  construct  a  general  purpose  command 
language  that  provides  the  means  for  computer  to  computer 
dialog.  This  is  another  element  of  computer  to  computer 
interfacing,  in  which  the  connecting  feature  is  a  command 
language  itself.  Command  languages  collectively  form  a  category 
of  intercomputer  connectivity,  in  which  the  type  and  purpose  of 
a  command  language  may  vary  widely  from  use  to  use.  One  of  the 
most  widely  recognized  command  languages  is  that  of  the  UNIX 
(trademark  of  Bell  Laboratories)  Time-Sharing  System  developed 
by  the  Bell  Telephone  Laboratories  (Ref  11:1905),  in  which  the 
most  visible  system  interface  is  the  "shell"  or  command 
language  interpreter,  through  which  other  programs  are  called 
into  execution  singly  or  in  combination  (Ref  6:1900).  The  UNIX 
shell  is  a  high-level  programming  language  that  provides  users 
with  an  interface  into  process  related  facilities  of  the  UNIX 
operating  system.  The  language  is  powerful,  concise,  flexible, 
and,  once  it  becomes  familiar,  easy  to  use.  It  serves  as  a 
useful  basis  of  comparison  for  other  command  languages  and  was  a 
source  of  guidance  for  this  project.  However,  the  degree  of 
difference  between  the  developed  command  language  for  the 
nova/eclipse  system  and  the  UNIX  shell  is  singularly 
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significant.  To  meet  the  particular  constraints  of  this 
project,  the  tiOVA/ ECLIPSE  command  language  was  developed  as  an 
interpretive  process  that  examines  tailored  files,  called  action 
files,  for  individually  connective  systems.  In  fact,  the 
pattern  of  development  parallels  the  so-called  PROCECURE  files 
utilized  within  the  CDC  NOS/BE  (Ref  7:5-21  -  5-38). 

The  CDC  PROCEDURE  files  allow  several  CDC  CYBER  commands  to 
be  combined  and  ordered  as  desired  into  a  single  package  for 
execution.  Each  file  has  a  header  and  body,  of  which  the  header 
statement  starts  the  header.  The  header  starts  with  the  keyword 
PROC.,  contains  the  name  of  the  procedure,  and  ends  with  the 
names  of  arguments  to  be  used  within  the  procedure.  The  next 
statements  of  the  file  are  the  body,  and  the  body  is  terminated 
with  an  end-of-record .  The  body  is  made  up  of  control 
statements,  which  are  inserted  into  the  job  control  stream  when 
the  PROCEDURE  file  is  called  into  execution.  The  PROCEDURE  file 
is  called  into  execution  by  a  call-by-name  statement  or  by  a 
call  statement  that  begins  with  BEGIN.  The  operating  system 
makes  the  appropriate  parameter  and  variable  substitutions 
within  the  PROCEDURE  file,  and  then  executes  the  file's  body  of 
statements.  Thus,  via  PROCEDURE  files,  users  of  NOS/BE  may 
combine  a  sequence  of  control  statements  (commands)  into  a 
single  command  with  a  variable  number  of  arguments.  The  entire 
sequence  may  be  executed  by  a  single  reference  to  the  name  of 
the  PROCEDURE  file,  eliminating  the  need  for  a  user  to  repeat 
minor,  often  used  commands,  such  as  REWIND.  It  also  allows  the 
computer  operating  system  to  keep  track  of  the  entire  command 


14 


sequence  without  user  intervention. 


The  KOVA/ECLIPSE  Coriputers 

The  DGC  NOVA  and  ECLIPSE  computers  are  both  16  bit  machines 
installed  within  the  digital  signal  processing  facility  of  the 
AFIT  EE  department.  The  NOVA  2/10  and  the  ECLIPSE  S/250  share  a 
ten  megabyte  disk  through  an  Inter-Processor  Buffer,  which 
arbitrates  simultaneous  disk  access.  Each  computer  operates 
under  a  Real-Time  Disk  Opei^ting  System  (RDOS),  which  is 
partially  resident  in  core  memory  as  well  as  on  the  disk  itself. 
Each  operating  system  starts  with  generation  of  SYSGEN,  a 
program  that  permits  the  RDOS  to  be  tailored  to  the  hardware  and 
software  configurations  available  at  a  location.  This  system 
generated  program  includes,  among  other  things,  the  number  of 
printers,  the  number  of  teletypes,  and  the  number  of  other 
devices  to  be  connected  to  and  recognized  by  the  operating 
system.  The  SYSGEN  created  program  for  the  ECLIPSE  is  called 
ESYS;  the  SYSGEN  created  program  for  the  NOVA  is  called  NSYS. 
NSYS,  however,  includes  the  generation  of  a  secondary  teletype 
for  both  input  and  output,  denoted  by  device  codes  $TTI1  and 
$TT01 ,  respectively.  Once  a  device  code  is  system  generated, 
the  operating  system  identifies  the  interrupts  of  the  device  and 
appropriate  handling  procedures.  This  investigation  required 
user  defined  interrupts  and  handlers  for  these  two  particular 
devices.  Hence,  another  program  was  generated,  called  NSYSl,  in 
which  the  operating  system  (RDOS)  did  not  "know"  about  device 
codes  $TTI1  and  $TT01 . 


Thnvigh  both  the  NOVA  and  ECI.II’SE  may  ph.ire  disk  files, 
there  are  differences  in  their  hardv;are  features  and 
capabilities.  The  AFIT  EE  department  decided  to  use  the  NOVA 
computer  as  the  interface  link  to  any  other  connected  system  and 
most  peripherals,  thereby  freeing  the  larger  and  faster  ECLIPSE 
for  actual  processing  of  data.  In  the  remainder  of  this  thesis, 
therefore,  the  term  NOVA/ ECLIPSE  will  be  used  to  indicate  that 
both  the  NOVA  and  ECLIPSE  computers  are  available,  yet  only  the 
NOVA  is  utilized  in  the  actual  interfacing  to  the  connected 
systems.  Thus,  all  device  codes  and  descriptions  may  be 
thought  of  as  pertaining  only  to  the  NOVA  2/10. 

In  order  to  connect  any  other  computer  system  to  the 
KOVA/ECLIPSE  computers,  access  is  required  to  the  computers 
themselves.  It  was  decided  to  make  use  of  standard  RS-232 
interface  connectors  and  modem  links,  wherein  the  NOVA  device 
codes  of  $TTI1  and  $TT01  would  serve  as  device  ports  for  the 
connected  system.  Information  from  the  NOVA/ECLIPSE  to  the 
connected  computer  system  would  be  transmitted  via  device  code 
$TT01 .  Information  from  the  connected  computer  system  to  the 
NOVA/ECLIPSE  would  be  transmitted  via  device  code  $TTI1. 
Because  of  the  way  RDOS  operates,  each  device  code  used  must  be 
assigned  an  integer  channel  number.  Accordingly,  throughout  the 
software  and  document  at  ion  that  is  developed,  device  codes  and 
channel  numbers  will  refer  to  the  same  entities,  particular 
device  codes  and  individual  channel  numbers  being  equated  at 
various  t ime s . 
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The  btisic  r.irthod  of  interaction  with  the  RDOS  is  through 
the  Command  Line  Interpreter  (CLI),  a  program  that  accepts 
command  lines  from  the  console  and  translates  them  into  RDOS 
commands.  Through  the  CLI,  high-level  compilers  like  FORTRAN 
may  be  invoked,  as  well  as  the  assembler  and  other  utilities. 
Interface  into  the  RDOS  can  also  be  achieved  via  system  calls 
and  task  calls.  Both  of  these  calls  were  utilized  within  the 
development  of  the  software  for  this  project.  Essentially,  the 
RDOS  can  be  addressed  directly  via  system  calls  in  a  program. 
The  general  form  of  a  system  call  is  (Ref  9:3-1): 

.SYSTM 

command  mnemonic 
error  return 
normal  return 

The  mnemonic  .SYSTM  precedes  each  system  com.mand,  which  passes 
control  through  the  RDOS  task  scheduler  to  the  system  call 
processor,  a  core-resident  portion  of  RDOS.  The  task  monitor 
saves  the  program  (or  task)  environment  in  a  special  block 
called  a  Task  Control  Block  (TCB)  and  saves  the  contents  of 
location  16,  the  User  Stack  Pointer  (USP),  before  passing 
control  to  the  call  processor.  Upon  execution  of  a  system  call, 
the  RDOS  takes  the  error  return  if  it  encounters  some  impediment 
while  executing  the  call.  Accumulator  two  contains  an  error 
code  that  describes  any  error  condition  and  may  be  displayed  by 
the  user.  If  the  call  succeeds,  the  RDOS  takes  the  normal 
return.  System  calls  are  detailed  in  the  RDOS  Reference  Manual, 
Chapter  3  (Ref  9:3-1  -  3-12).  A  task  call  is  similar  to  a 
system  call,  except  for  the  following  points.  Task  calls  have 
no  .SYSTM  mnemonic  before  the  task  command  mnemonic.  The  RDOS 
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executes  task  calls  in  user  address  space,  whereas  system  calls 
are  executed  in  operating  system  space.  And  finally,  many  task 
calls  have  no  error  returns.  The  details  of  task  calls  may  be 
found  in  the  RDOS  Reference  Manual  as  v/ell  (Ref  9:5-1  -  5-8). 
Other  conventions  of  the  RDOS  and  NOVA/ECLIPSE  computers  will 
be  introduced  and  explained  as  encountered  in  the  discussion  of 
the  project  development. 

Modes  of  Oper a t i on 

The  most  direct  method  of  connecting  the  local  NOYA/ECLIPSE 
computers  to  any  other  computer  system,  particularly  the  locally 
accessible  CDC  CYBER  system,  is  via  a  standard  RS-232  interface 
link  to  one  of  many  available  modems.  The  simplest  method  of 
interconnection  is  to  allow  a  local  NOVA  terminal  to  act  as  a 
transparent  CYBER  terminal,  i.e.,  as  if  the  NOVA  terminal  were 
directly  connected  to  the  CYBER  and  not  the  NOVA.  This  requires 
a  software  interface  that  allows  the  NOVA  computer  to  accept 
data  in  from  the  CYBER,  display  to  the  local  terminal,  and 
vice-versa.  This  at  least  allows  access  via  the  NOVA  computer 
to  the  connected  computer  system,  but  it  does  not  allow  file 
transfers  or  any  other  direct  intercommunication  between 
systems.  Thus,  to  extend  the  concept  further,  additional 
software  is  needed  to  enable  direct  access  from  one  computer  to 
the  other.  One  method  of  doing  this  is  to  create  a  program  to 
mesh  the  NOVA  with  a  particular  system  to  the  degree  that  files 
on  either  system  are  accessed  by  the  user  on  the  NOVA.  It  was 


recognized  early  that  such  software  should  be  designed  to  be 


independent  of  a  particular  system.  Hence,  a  more  general 
software  product  was  desired  that  allows  interaction  between  the 
NOVA/ECLIPSE  and  a  variety  of  other  computer  facilities. 

Since  each  computer  system  is  somewhat  different,  a  method 
was  needed  to  confront  these  differences  in  a  general  fashion  by 
the  local  NOVA/ECLIPSE  system.  If  a  particular  segment  of  the 
software  was  designed  to  be  compatible  with  a  particular 
connected  system,  then  the  NOVA  would  have  to  be  able  to  select 
that  software  and  use  it  on  demand.  Further,  the  act  of 
selection  should  not  tie  the  NOVA  to  the  selected  system,  as  a 
different  system  nay  be  desired  at  a  later  time.  To  meet  these 
constraints,  the  pattern  of  a  so-called  action  file  was 
conceived,  based  upon  the  general  concepts  of  a  PROCEDURE  file 
as  utilized  in  the  CDC  NOS /BE. 

To  extend  this  concept  to  the  local  NOVA/ECLIPSE  system, 
both  the  action  file  (patterned  after  the  PROCEDURE  file)  and  a 
method  of  reading  and  acting  upon  the  action  file  was  required. 
Once  one  or  more  action  files  could  be  constructed  on  the  NOVA 
system,  how  could  they  be  utilized?  In  the  simplest  context, 
the  action  file  may  be  thought  of  as  a  simple  list  of  command 
sequences  to  be  executed  by  the  system.  A  method  was  needed  to 
read  each  sequence  of  instructions  and  send  them  to  the 
connected  system  to  be  executed.  This  presented  additional 
considerations.  First  of  all,  the  action  file  sequences,  if 
more  than  one,  must  be  distinguishable  from  each  other.  When 
and  where  would  one  sequence  start  and  end?  Secondly,  the 
connected  system  may  respond  at  some  time  and  in  some  fashion  to 
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inputs,  perhaps  requiring  that  responses  somehow  be 
acknowledged.  Thus,  what  responses  would  be  expected  and  how 
or  when  should  they  be  acknowledged?  Thirdly,  sending 
instructions  to  the  connected  system  limits  the  local  system  in 
taking  independent  action.  Thus,  there  must  be  some  capability 
of  instructing  the  local  system  in  the  midst  of  action  file 
execution.  Each  of  these  considerations  and  questions  led  to 
the  idea  of  an  action  file  interpreter  —  a  program  that  would 
seek  out  the  desired  action  file,  initiate  and  terminate 
selected  command  sequences,  allow  for  responses  to  the  connected 
system,  and  alert  the  local  NOVA/ECLIPSE  system  to  necessary 
inputs  and  outputs.  Thus,  the  basic  idea  for  computer  to 
computer  dialog  regarding  the  NOVA/ECLIPSE  system  revolved 
around  the  design  and  development  of  action  files  peculiar  to 
possible  connected  systems  and  a  general  interpreter  for  the 
action  files.  The  process  of  designing  these  began  by 
considering  a  specific  system  to  work  with,  and  the  natural 
choice  was  the  CYBER  system. 
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III.  Development  of  the  Program 

The  development  of  the  software  to  permit  the  NOVA/ECLIPSE 
computers  to  be  interconnected  to  another  computer  system  was 
done  in  a  top-down  manner,  using  successive  refinement.  This 
chapter  describes  the  software  development  of  three  specific 
software  parcels:  (a)  program  TTERMOP,  (b)  program  MONITOR,  and 
(c)  the  action  files.  The  program  TTERMOP  is  a  program  that 
allows  the  user  on  the  NOVA/ECLIPSE  terminal  to  operate  in  the 
transparent  terminal  only  mode.  The  program  MONITOR  is  the 
command  language  interpreter  that  reads  and  acts  upon  selected 
action  files.  The  action  files  are  created  in  a  prescribed 
manner  that  meets  the  expectations  of  the  interpreter.  The 
action  file  referenced  within  this  text  is  that  created  and 
implemented  to  intercommunicate  with  the  CDC  CYBER  computer 
system.  The  development  of  MONITOR  and  the  action  files  was 
interdependent  and  cannot  be  artificially  separated. 
Nonetheless,  the  following  text  does  treat  the  development  of 
each  somewhat  separately,  first  describing  the  generation  of  the 
action  files  and  then  the  program  MONITOR.  Before  these 
discussions  are  presented,  some  theory  and  background  concerning 
the  development  are  presented,  in  order  to  acquaint  the  reader 
with  the  overall  concepts  and  implementation  conventions. 
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Development  Theory  and  Background 


After  analyzing  the  problem  and  deciding  that  three 
partitionable  software  products  were  to  be  developed  —  program 
TTERMOP,  program  MONITOR,  and  the  action  files  —  the 
alternative  methods  of  accomplishment  and  the  tools  to  be  used 
in  the  development  were  considered.  Some  factors  bearing  upon 
the  considerations  were  the  stated  objectives  of  the  solution  to 
the  problem  itself.  The  program  MONITOR  should  be  as  flexible 
as  possible,  so  as  to  be  utilized  with  as  many  connected 
systems  as  possible.  Also,  program  MONITOR  should  be  as 
general  as  possible,  so  as  to  be  a  completely  portable  (to  the 
degree  possible)  program  that  could  be  hosted  on  other  systems, 
in  addition  to  the  NOVA/ ECLIPSE .  This  dictated  that  the  action 
files  be  dependent  upon  the  connected  system  for  content,  but 
independent  of  the  connected  system  as  far  as  structure.  One 
final  factor  was  to  develop  a  system  that  enabled  the 
NOVA/ECLIPSE  computers  to  interact  with  the  CDC  CYBER  computer 
system . 

In  consideration  of  these  factors,  the  software  needed  to 
be  developed  in  as  high-level  a  language  as  permissible,  thereby 
supporting  its  generality.  PASCAL  was  a  logical  choice.  A 
structured  language,  such  as  PASCAL,  leads  to  simplified  data 
structures  and  more  straightforward  file  structure 
manipulations.  In  addition,  PASCAL  has  powerful  features,  such 
as  recursion,  that  enable  complex  algorithms  to  be  more  readily 
designed  and  developed.  Nonetheless,  PASCAL,  was  not  available 
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on  the  NOVA/ECLIPSE  computers  at  the  time  of  development. 
Other  structured  languages  that  seemed  to  lend  themselves  to 
this  type  of  undertaking  were  not  available  either.  FORTRAN  IV 
and  FORTRAN  V  wore  available.  FORTRAN  IV  was  selected  because 
it  was  available,  is  a  high-order  language,  and  is,  perhaps,  as 
universal  a  language  as  exists.  FORTRAN  V  was  not  selected 
because  of  the  case  for  FORTRAN  IV  and  the  fact  that  FORTRAN  V 
is  essentially  a  superset  of  FORTRAN  IV.  Thus,  if  a  user 
chooses,  FORTRAN  IV  may  be  extended  to  FORTRAN  V.  It  also 
seemed  reasonable  at  the  outset  to  expect  to  use  some  assembly 
language  programs  to  implement  device  handlers  and  routines  that 
depended  heavily  upon  the  operating  system  characteristics. 
Thus,  both  the  DGC  FORTRAN  IV  and  assembly  languages  are  used  to 
develop  the  software  parcels.  Some  variations  from  the 
American  National  Standards  Institute  (ANSI)  standard  FORTRAN 
were  utilized,  but  only  to  enhance  readability  and 
understanding.  None  of  the  uses  would  preclude  adaptation  to 
other  system  FORTRAN  versions,  depending  upon  the  assembly 
language  that  may  be  required  for  another  system. 

Transparent  Terminal  Mode .  The  idea  to  create  a 
transparent  terminal  mode  of  operation  was  two-fold.  First, 
the  terminal  mode  would  at  least  allow  access  to  another  system. 
Depending  upon  the  ultimate  limitations  of  a  command  language, 
such  a  mode  would  be  desirable  to  permit  detailed  interaction 
with  a  connected  system  not  possible  at  the  higher  level  of  the 
command  language.  Further,  such  a  mode  would  serve  as  a  handy 
option  for  transitioning  in  the  middle  of  any  command  langauge 


23 


execution.  Secondly,  the  development  of  a  terminal  mode  would 
be  a  prelude  to  other  developments.  Such  a  prelude  would 
provide  system  familiarization  and  understanding  in  a  less 
complex  environment. 

The  first  and  major  obstacle  in  developing  the  program 
TTERMOP  was  the  method  of  interaction  to  be  implomet.ted  between 
connected  systems.  The  transparent  terminal  mode  needs  to  be 
controlled  by  the  user  at  the  local  NOVA  terminal.  Outputs  to 
the  connected  computer  system  are  generated  by  entries  made  by 
the  terminal  user.  However,  responses  from  the  connected  system 
are  less  controlled,  and,  more  generally,  may  vary  from  one 
system  to  another.  There  may  be  responses  during  the  access 
initiation  process,  after  individual  instructions  are  received, 
or  upon  other  occasions  unexpected  by  the  user.  Implementation 
of  interrupt  servicing  seemed  the  logical  alternative  to 
overcome  this  control  problem  in  the  most  general  case.  This, 
in  turn,  also  lead  to  a  problem  in  implementation,  for 
interrupts  are  usually  serviced  by  the  operating  system  for 
devices  known  by  the  system,  i.e.,  generated  when  the  system  is 
initially  brought  up  to  operation.  In  order  to  use  interrupts, 
then,  either  the  system  generated  interrupt  service  routines  had 
to  be  changed  to  allow  different  interrupt  handling,  or  the 
interrupts  had  to  be  removed  from  the  purview  of  the  operating 
system  and  be  generated  by  the  developed  software.  The  latter 
alternative  was  chosen,  since  changing  the  operating  system 
handlers  was  more  complex  and  would  still  leave  the  handlers  in 
the  system.  Other  users  with  other  programs  would  not 
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necessarily  find  changed  operating  system  handlers  useful  or 
expected.  As  mentioned  in  Chapter  II,  the  device  codes  to  be 
used  for  purposes  of  intercommunication  are  $TT0l  and  $TTI1. 
Both  these  devices  and  their  codes  are  removed  in  the  system 
generated  program  NSYSl.  Thus,  developsient  of  TTERMOP  was  now 
possible  using  defined  interrupts  and  handlers  within  the 
software  itself. 

A  second  obstacle  existed  that  hindered  TTERMOP 
development.  Even  though  interrupts  were  available  to  permit 
servicing  for  the  two  NOVA/ECLIPSE  port  devices  ( $TT01  and 
$TTI1),  the  program  software  needed  to  respond  to  both  the  local 
terminal  inputs  and  outputs  —  interrupts  that  remained  defined 
by  the  operating  system  —  and  the  connected  system  inputs  and 
outputs  —  interrupts  that  were  program  defined.  The 
possibility  existed  that  the  program  might  be  servicing  one  of 
these  sets  of  inputs/outputs,  and  lose  input  s/output s  from  the 
other  set.  Some  method  of  asynchronous  interaction  was  needed 
to  insure  both  sets  of  inputs/outputs  were  equally  and  promptly 
handled.  The  NOVA/ECLIPSE  system  has  such  a  capability,  called 
multitasking  (Ref  7:5-1+).  Multitasking  permits  a  single 
program  to  contain  multiple,  competitive  tasks.  A  task  is  a 
complete,  self-contained  execution  path  through  a  program,  which 
demands  system  resources.  In  a  single  task  environment,  a 
program  has  a  single  unified  path  connecting  all  its  program 
logic,  no  matter  how  complex  the  logic  branches.  In  a 
multitask  environment,  a  program  may  have  two  or  more  logically 
distinct  tasks,  each  with  its  own  priority.  Each  of  these 
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distinct  tasks  performs  a  specified  function  asynclironous  ly  and 
in  real-time.  In  the  RDOS,  the  Task  Scheduler  allocates 
central  processor  control  to  the  highest  priority  task  that  is 
ready  to  perform  its  function.  The  taul titasking  feature  of  the 
RDOS  is  used,  then,  to  put  the  interrupts  for  the  connected 
system  into  one  task  for  processing,  while  the  interrrupts  for 
the  NOVA  terminal  are  put  into  a  logically  distinct  task.  To 
insure  the  user  maintains  control,  the  task  that  controls  the 
NOVA  terminal  is  given  the  higher  priority. 

The  Action  Files.  The  concept  for  the  action  file  came 
directly  from  the  CDC  NOS/Eh  PROCEDURE  files  (Ref  7:5-21  - 
5-38).  A  separate  action  file  was  conceived  for  particular 
computer  systems  to  be  interfaced  with  the  NOVA/ECLIPSE 
computers.  Each  action  file  contains  a  sequence  of  commands,  of 
which  each  command  in  the  sequence  instructs  either  the 
NOVA/ECLIPSE  or  the  connected  system.  These  instructions  serve 
the  same  purpose  as  the  body  of  the  PROCEDURE  file,  i.e.,  they 
provide  the  control  statements  necessary  for  execution  of  a 
command.  The  header  statement  of  the  action  file  was  conceived 
to  be  essentially  the  same  as  that  for  the  PROCEDURE  file.  It 
contains  a  keyword  that  identifies  the  action  file,  such  as 
.CACT  for  the  CYBER  action  file.  The  keyword  is  followed  by  a 
command  name  and  argument  parameters.  To  facilitate 
segregation  of  each  sequence  from  the  next,  another  keyword  is 
inserted  into  the  file  between  sequences.  This  keyword  is  END.. 
Similarly,  to  denote  the  end  of  the  action  file,  the  keyword 
FINISH,  is  used.  To  allow  the  action  file  to  be  as  powerful  as 
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possible,  and  .hence,  the  interpreter  as  general  as  possible,  a 
method  to  incorporate  expected  system  responses  is  developed. 
At  the  beginning  of  each  action  file,  the  control  character  "I" 
must  be  included  .  It  is  followed  by  up  to  two  separate 
responses  that  may  be  expected  of  the  system.  (These  responses 
are  used  in  the  interpreter  to  detect  the  occurrence  of  system 
responses  and  to  detect  the  end  of  such  responses.)  Other 
features  of  the  action  files  follow  logically  from  the 
requirements  of  the  program  MONITOR. 
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MONITOR  is  the  fundamental  part  of  the  software  package. 
Program  MONITOR  is  developed  to  instruct  the  interactive  user 
step  by  step  in  the  execution  of  the  software  that  forms  the 
command  language.  Thus,  the  program  first  identifies  itself  via 
a  display  on  the  user's  terminal  (NOVA/ECLIPSE)  and  identifies 
the  action  files  that  are  available  for  selection.  (Four  action 
files  are  available  to  the  user,  of  which  only  one  is  totally 
implemented.  The  others  are  shells  that  await  future 
completion.  The  complete  action  file  is  for  the  CDC  CYBER 
computer  system,  called  .CACT  .  Two  action  files  are  for 
computers  that  are  accessible  locally,  even  though  connections 
have  not  been  attempted.  They  are  called  . DACT  and  .VACT  .  The 
last  action  file  is  completely  arbitrary,  and  is  available  for 
any  user  to  generate  as  desired.  This  file,  called  .MACT, 
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presents  the  ultimate  in  flexibility  —  the  creation  of  a 
totally  user-defined  and  user-raodif  iable  action  file  for  any 
systen.)  Program  MONITOR  requests  the  user  to  select  an  action 
file  and  then  requests  the  user  to  LOGON.  (Procedures  for  LOGON 
and  the  other  commands  are  contained  in  the  MONITOR  User 
Manual,  Appendix  A.)  To  notify  the  user  that  a  response  is 
required,  program  MONITOR  provides  a  prompt.  Program  MONITOR 
also  screens  input  commands  to  determine  if  they  are  valid;  for 
example,  rejecting  commands  not  within  the  action  file,  commands 
that  are  too  long,  commands  that  are  without  the  necessary 
arguments,  and  commands  that  contain  syntax  errors. 

Program  MONITOR  was  developed  in  a  simple  configuration  to 
expedite  its  implementation.  In  this  configuration,  commands 
arc  required  to  be  entered  and  followed  by  exactly  the  number  of 
arguments  expected,  that  is,  the  number  of  arguments  indicated 
after  the  command  name  in  the  action  file.  Furthermore, 
commands  must  be  in  the  same  order.  There  are  no  optional 
arguments  nor  default  arguments.  This  configuration  simplifies 
the  decision-making  of  the  interpreter  with  regard  to  parameter 
substitution.  Also,  there  are  two  control  options  that  the  user 
may  exercise  at  any  time  in  lieu  of  command  strings.  One  of 
these  is  the  entry  "*T",  (an  up-arrow  and  T)  which  causes  the 
program  MONITOR  to  relinquish  control  to  the  terminal  operation 
only  mode.  The  other  option  is  the  entry  "“'L",  (an  up-arrow 
and  L)  which  causes  a  return  to  the  RDOS  CL  I . 

A  similar  obstacle  to  that  of  TTERMOP  hindered  development 
of  MONITOR.  This  was  the  control  of  inputs  and  outputs  of  the 


connected  system  and  inputs  and  outputs  of  the  KOVA/ECLIPSK . 
The  solution  was  again  multitasking,  with  one  task  monitoring 
NOVA/ECLIPSE  input/output  and  the  other  task  monitoring  the 
connected  system's  input/output.  An  additional  obstacle  not 
encountered  before  concerned  instructing  the  KOVA/ECLIPSE  RDOS 
from  vjithin  the  program  MONITOR.  As  the  program  MONITOR 
executes  in  RDOS  already,  some  method  to  exit  the  program 
MONITOR  is  needed  in  order  to  instruct  RDOS  via  its  own  command 
language,  the  CLI ,  It  is  equally  necessary,  however,  to  be  able 
to  reenter  MONITOR  immediately  after  any  instruction  is  passed 
to  RDOS,  and  to  enter  at  the  location  from  which  the  exit 
occurred.  One  feasible  means  of  doing  this  is  to  swop  out  the 
program  MONITOR,  swap  in  the  RDOS  CLI,  and  then  swap  right  bac’. 
to  the  program  MONITOR.  The  process  of  swapping  is  available  on 
the  MOVA/ECLIPSE  system  via  system  and/or  task  calls  to  the 
operating  system. 

Swapping  as  implemented  on  the  DGC  system  is  a  process 
whereby  a  program  is  called  by  name  into  execution.  The  calling 
program  is  swapped  out  of  memory  and  the  called  program  is 
swapped  into  memory.  Within  the  RDOS,  the  CLI  normally  operates 
on  what  is  called  level  zero.  This  is  the  highest  of  five 
possible  levels  of  program  execution.  When  a  typical  program  is 
called  into  execution  by  the  CLI,  the  program  is  executed  on 
level  one.  In  effect,  the  CLI  is  swapped  out  of  memory  and  the 
executing  program  is  swapped  into  memory.  Going  from  one  level 
to  another  is  essentially  a  stack  operation.  If  the  CLI  is 
executing  on  level  zero  and  a  program  is  called  into  execution, 
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tlio  exccutiiu;  piogran  is  pushed  onto  the  stack.  Returning  to 
the  CLl  at  tlie  program's  conclusion  is  essentially  a  pop  of  the 
stack.  The  latest  program  on  the  stack  is  the  level  being 
executed.  If  the  CLI  is  executing  on  level  zero,  it  is  not 
possible  to  execute  another  program  from  the  CLI  without  that 
program  starting  execution  at  its  beginning.  The  ability  to 
communicate  with  RDOS,  however,  can  be  accomplished  as  desired 
by  calling  the  CLI  into  operation  on  level  tv;o.  Then,  when  the 
CLI  execution  is  complete,  an  appropriate  pop  of  the  stack  will 
return  to  the  level  one  program.  Furthermore,  the  return  will 
be  to  the  location  from  which  the  program  called  the  CLI  into 
execution  on  level  tv;o.  Executing  the  CLI  on  level  two  can  be 
limited  to  a  single  instruction  or  a  group  of  instructions  that 
are  passed  at  the  time  of  the  call  to  svjap  to  the  CLI.  The 
process  is  described  more  completely  in  the  RDOS  Reference 
Manual,  Chapter  4  (Ref  7:4-2). 

Dev e 1 c pment  o f  TTERHOP 

As  mentioned  earlier,  the  port  device  codes  $TTI1  and  $TT01 
were  incorporated  into  the  software  of  TTERKOP  and  MONITOR, 
rather  than  leaving  the  operating  system  to  define  them  in  its 
SYSGEN  program.  The  advantage  of  identifying  the  device  codes 
at  run  time  is  that  now  interrupt  handlers  can  be  designed  to 
handle  interrupts  as  desired.  By  doing  this,  any  input  to  the 
NOVA/ECLIPSE  computers  from  the  connected  computer  system 
generates  an  interrupt  via  device  code  $TT11.  The  interrupt 
service  routine  essentially  accepts  the  input  and  stores  it  in  a 
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buffer  foT  later  disposition.  Similarly,  any  output  from  the 
NOVA/KCLIPSE  computers  to  the;  connected  computer  system 
generates  .•’u  interrupt  via  device  code  $TT01  .  This  interrupt 
service  routine  simply  clears  the  particular  inte^rrupt,  allov/ing 
the  connected  computer  to  handle  the  MOVA/ECLIPSE  oitj>ut  in  its 
own  fashion.  (It  should  be  noted  that  all  input  and  output  is 
I'.mited  to  ASCII  characters  in  all  the  software  developed.) 

Once  the  input  from  the  connected  computer  system  is 
received  by  the  NOVA  (wiiere  in  fact  the  device  ports  exist)  and 
is  stoied  in  a  buffer,  a  separate  section  of  code  disposes  of 
the  buffer  itself.  Two  Pointers  are  established.  One  pointer, 
called  INPTR,  points  to  the  next  empty  location  in  tlic  buffer. 
The  other  pointer,  called  OIITPTP,,  points  to  the  last  buffer 
location  actually  disposed  of  by  program  TIER MOP.  If  the  buffer 
has  not  been  accessed  by  the  program,  OUTFTR  started  and  remains 
at  the  buffer's  beginning.  If  the  IKPTR  and  OUTPTR  point  to  the 
same  location,  the  program  knows  that  the  buffer  is  "empty." 
Conversely,  whenever  the  pointers  are  not  the  same,  input  has 
been  received  and  stored  in  the  buffer.  The  buffer  itself  is 
designed  to  be  132  characters  long.  This  arbitrary  length  was 
selected  with  the  reasonable  expectation  that  the  buffer  would 
never  ovorflo\7,  i.e.,  that  the  INPTP,  would  not  be  132  characters 
ahead  of  the  OUTPTR  at  any  time.  The  expectation  seemed 
particularly  reasonable  when  considering  the  300  baud  rate  of 
the  CDC  CYRER,  used  as  the  implementing  connected  system.  This 
should  be  the  case  for  higher  baud  rates  as  well,  particularly 
1200  baud.  Even  at  rates  up  to  4800  baud,  the  buffer  should  be 
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adequate. 

The  section  of  code  in  program  TTERMOP  that  looks  at  the 
buffer  continually  is  named  LINgRD,  and  is  called  as  a  separate 
task  within  the  multitasking  framework  of  the  program  TTERMOP. 
LINERD  has  a  priority  of  ten,  whereas  the  main  task  of  TTERMOP, 
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terminal  and  transmits  it  directly  to  the  connected  system  via 
device  code  $TT01 .  The  task  LINERD  simply  takes  input  from  the 
input  buffer,  and  displays  it  to  the  NOVA  terminal.  In 
operation,  then,  the  user  generates  output  and  usually  awaits 
input.  Since  the  output  program  has  higher  priority,  the  user 
controls  the  program.  While  the  user  awaits  input,  the  lower 
priority  task  LINERD  seizes  control  of  the  processor  to  look  for 
that  input.  At  rates  up  to  at  least  1200  baud,  both  tasks 
appear  to  operate  simultaneously  and  are  in  fact  seizing  control 
on  a  character  by  character  basis. 

Program  TTERMOP  has  several  parts  to  it.  The  program 
contains  the  separate,  logical  tasks  LINERD  and  TERMED.  The 
program  also  has  the  system  calls  to  identify  and  generate 
device  codes  $TT01  and  $TTI1 .  Finally,  TTERMOP  has  the 
interrupt  handlers  defined  within  its  source  code  also. 
Altogether,  the  program  provides  the  necessary  software  to  make 
the  NOVA/ECLIPSE  user  operate  off  of  the  connected  system,  in 
particular  the  CYBER  system,  transparently.  Since  the  majority 
of  the  functions  dealt  with  in  this  program  are  at  the  device 
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driver  level,  the  entire  source  code  is  assembly  language.  A 
higher-level  flowchart  of  the  program  TTERMOP  is  not  explicitly 
provided.  However,  a  flowchart  for  program  TERMOP  contained  in 
Appendix  B  is  exactly  the  same  for  TTERMOP,  and  may  be  referred 
to  for  information  concerning  TTERMOP. 

Program  TTERMOP  is  executed  by  entering  the  directory 
DIALOG  and  typing  on  the  NOVA  terminal  TTERMOP.  Once  a 
telephone  connection  via  a  modem  is  established  betv/ecn  the 
CYBER  and  the  NOVA/ ECLIPSE ,  all  subsequent  terminal  action  is  as 
if  the  NOVA  terminal  were  directly  connected  to  the  CYBER.  All 
NOVA/ECLIPSE  operations  are  transparent  to  the  user  during  the 
execution  of  the  program  TTERMOP.  Exit  from  TTERMOP  may  be 
accomplished  by  typing  in  an  up-arrow  at  any  time,  thus 
reverting  the  user  to  the  RDOS  CLI. 

Devc  1  opinent  of  the  Action  Files 

One  of  the  very  first  things  considered  when  starting  the 
construction  of  the  general  purpose  interface  for  the 
NOVA/ECLIPSE  computers  was  the  minimum  number  of  instructions 
required  as  input  by  a  connected  computer  system,  in  order  for 
that  system  to  execute  functions  on  its  own  file  structure. 
This  minimal  set  of  instructions  formed  the  initial  action  file 
and  served  as  a  forerunner  of  the  final  product.  As  stated  in 
Chapter  II,  the  CDC  CYBER  PROCEDURE  files  were  the  pattern 
behind  the  design  of  the  action  files.  Thus,  the  initial  action 
file  was  closely  structured  after  the  PROCEDURE  file.  Both 
files  have  header  statements  that  declare  the  name  and  arguments 
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of  a  particular  command  sequence.  Both  files  have  a  body  of 
statements  that  consist  of  the  control  command  sequences,  and 
both  files  have  all  entries  arranged  sequentially.  This 
sequential  arrangement  is,  in  turn,  the  logical  and  convenient 
means  by  which  to  examine  the  action  files.  Once  the 
interpreter  selects  an  appropriate  action  file  and  receives  a 
command  input,  the  file  is  sequentially  examined  from  the 
beginning  until  a  command  name  matches  the  input  command.  Once 
the  match  is  made,  each  instruction  within  the  sequence  is  acted 
upon  and  executed  sequentially  as  v;ell.  Keywords  are  inserted 
within  the  action  file  to  isolate  instruction  sequences  and 
indicate  file  beginning  and  end.  Again  borrowing  heavily  from 
the  PROCEDURE  file,  the  start  of  each  action  file  is  simply  the 
file  itself.  The  start  of  a  particular  command  sequence  in  the 
file  is  denoted  by  a  single  period  appearing  as  the  first 
character  in  the  line  of  the  sequence,  followed  by  a  descriptor. 
The  descriptor  for  the  CDC  CYBER  action  file  is  the  word  ".CACT" 
.  This  descriptor  is  follov/ed  by  the  name  of  the  command 
sequence  and  any  arguments  as  required.  The  arguments  are 
simply  a  series  of  sharpsigns  (#)  and  integers,  which  denote 
the  order  and  position  of  the  arguments  in  the  header 
statement.  (As  noted  earlier,  position  is  fixed.)  Each  entry  is 
arbitrarily  separated  by  commas.  After  this  first  line, 
referred  to  as  the  action  file  header,  is  a  list  of  command 
instructions  that  comprise  a  command  sequence.  To  delimit 
individual  command  instruction  sequences,  the  keyword  "END."  is 
used.  Finally,  to  indicate  the  last  line  in  the  action  file. 
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the  keyword  "FINISH."  is  irserted.  Figure  1  shows  a  skeletal 
outline  of  an  action  file  for  the  CDC  CYBER  as  presented  thus 
f  ar . 


. CACT , COMMANDNAMEl , #1 , #2 

YYYYY  dummy  instructions  that 

ZZZZZ  form  a  command  sequence 

END. 

.CACT.COMMAMDNAME  no  arguments 

YYYYY 

ZZZZZ 

END. 

.CACT,C01'1MANDNAHEN,#1  ,#2,  .  .  .  ,#N 
YYYYY 

ZZZZZ 

END. 

FINISH. 


Fig  1.  Skeletal  Command  Action  File 


With  respect  to  the  action  file,  the  command  language 
interpreter  reads  the  action  file,  matches  the  desired  command 
name,  and  then  sends  the  instructions  within  the  matched 
command  sequence  to  the  connected  system  or  to  the  local 
nova/eclipse  system  for  execution.  To  simplify  the  decision 
process  of  the  interpreter,  the  action  file  includes  control 
characters  within  each  command  sequence  to  direct  interpreter 
handling.  Each  of  these  control  character  sets  has  two  control 
characters.  For  example,  an  instruction  within  the  sequence 
that  calls  for  writing  to  the  local  NOVA  terminal  is  preceded  by 
the  control  character  set  WL.  Other  examples  of  control 
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character  sets  are  WS,  write  to  the  connected  system;  RS,  read 
from  the  connected  system;  and  RW,  read  froti>  the  local  system 
terminal  and  then  write  a  single  carriage  return  to  the 
connected  system.  Two  particular  control  character  sets  are  RC 
and  WC.  These  character  sets  precede  an  instruction  that  is 
directed  to  the  IIOVA/ ECLIPSE  RDOS .  The  first  set  results  in  a 
disk  file  on  the  NOVA/ECLIPSE  being  read  and  copied  to  the 
connected  system.  The  second  set  results  in  a  file  being 
written  to  the  NOVA/ECLIPSE  disk  from  information  copied  from 
the  connected  system.  These  character  sets  put  into  motion  a 
swap  to  the  RDOS  CLI,  as  explained  briefly  in  Chapter  II  and 
more  fully  described  in  the  next  section. 


C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  SENT 

C  CORRECT  INPUT  IS:  PUT , LFN , SFN , ID , SFPASSWRD 

.CACT,PUT,#l,#2,i!i3,#4 

WS  COPYBF, INPUT, ZQY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, ZQY 

WS  REQUEST, ZQZ,*PF 

WS  COPYBF, ZQY, ZQZ 

WS  CATALOG, ZQZ, #2, ID=#3,RP=999,PW=#4 

WS  RETURN, ZQZ, ZQY 

END. 

C  THIS  COMMAND  RECEIVES  SYSTEM  FILES 
C  CORRECT  INPUT  IS:  GET , SFN , ID , SFPASSWRD , LFN 

.CACT,GET,#1 ,#2,#3,#4 
WS  ATTACH, QZQ,#1,ID=#2,PW=#3 

RR 

WS  COPYSBF,QZQ, OUTPUT 

RC  XFER/A  VVQQ  #4/R 

WS  RETURN, QZQ 

END. 


Fig  2.  Sample  from  CYBER  Action  File 


36 


An  example  portion  of  tho  final  CYBER  action  file  is 
illustrated  in  Fij^ure  2.  The  first  command  name  st.own  is  PUT. 
This  command  takes  a  disk  file  resident  on  the  NOVA/ECLIPSE 
system  and  transfers  the  file  to  permanent  storage  on  the  CDC 
CYBER  system.  The  command  name  PUT  is  preceded  by  the  keyword 
.CACT  and  followed  by  the  place  holders  for  four  arguments. 
Therefore,  the  PUT  command  requires  four  arguments.  In  order, 
these  arguments  must  be  the  local  file  name  (including  any 
directory  specifiers)  of  the  NOVA/ ECLIPSE  disk  file,  the  system 
file  name  to  be  used  on  the  CYBER,  the  user  identification 
number  or  problem  number  the  file  is  to  be  stored  under,  and  the 
CYBER  syst  m  passwords.  (Since  each  argument  parameter  is 
required,  a  parameter  must  be  used  for  the  password.  In  this 
case,  and  only  in  this  case,  a  zero  entry  may  be  used  to 
indicate  no  password.)  The  first  instruction  in  the  PUT  command 
sequence  is  preceded  by  WS,  and,  as  with  all  instructions, 
arbitrarily  starts  in  column  nine.  Thus,  the  instruction 
consisting  of  the  string  —  COPYBF, INPUT, ZQY  —  is  to  be  sent  to 
the  CYBER.  The  next  command  in  the  sequence  is  preceded  by  WC. 
This  means  that  the  file  with  the  name  entered  in  the  position 
of  argument  one  is  to  be  copied  from  the  NOVA/ECLIPSE  disk  to 
the  CYBER  system.  All  the  rest  of  the  commands  in  the  sequence 
are  preceded  by  WS,  and  explicitly  instruct  the  CYBER  to  store 
the  transferred  file  into  permanent  file  storage,  the  user  input 
arguments  having  been  substituted  for  the  argument  parameters 
within  the  action  file  by  manipulation  of  the  interpreter.  The 
command  sequence  terminates  with  END. 
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The  second  command  name  shown  is  GET.  This  command  takes  a 


file  in  permanent  storage  on  the  CYBER  and  transfers  the  file 
to  the  KOVA/ECLIPSE  disk.  The  command  GET  is  also  preceded  by 
the  keyword  .CACT  and  followed  by  the  placeholders  for  four 
arguments.  The  treatment  of  these  four  arguments  is  exactly  the 
same  as  that  for  PUT,  with  the  order  and  position  strictly 
observed.  Hence,  the  arguments  in  order  must  be  the  system  file 
name,  the  user  identification  number,  the  system  file  password, 
and  the  local  file  name.  The  commands  in  the  sequence  preceded 
by  WS  are  handled  exactly  as  described  for  PUT  above.  A  blank 
commend  line  is  preceded  by  the  control  character  set  RR,  which 
is  sufficient  to  tell  the  interpreter  that  the  local 
nova/eclipse  needs  to  ready  itself  for  a  read  from  the  CYBER. 
Essentially,  the  character  set  RR  activates  a  subroutine  to 
create  a  temporary  file  that  will  subsequently  be  written  into, 
when  the  next  instruction  in  the  action  file  preceded  by  RC  is 
executed.  The  command  line  preceded  by  RC  is  just  the  converse 
of  the  command  line  preceded  by  V/C.  In  this  case,  file  transfer 
takes  place  from  the  CYBER  to  the  NOVA/ ECLIPSE .  Again,  the 
command  sequence  is  terminated  by  the  keyword  END. 

Finally,  single  control  characters  are  used  outside  of  the 
command  sequence.  The  control  character  C,  for  example, 
indicates  that  the  remainder  of  the  line  is  a  comment  that  the 
interpreter  may  ignore.  (There  is  one  other  single  control 
character  —  I  --  used  elsewhere  in  the  action  file.  It 
indicates  that  up  to  two  responses  of  the  connected  system  may 
follow.  Even  if  no  responses  are  expected  nor  entered,  the 
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control  character  I  must  be  in  the  action  file  as  the 
interpreter  always  looks  for  it.) 

Development  of  MONITOR 

Program  MONITOR  is  the  largest  software  partition  utilized 
in  interfacing  the  NOVA/KCLIPSE  computers  to  other  connected 
computer  systems.  MONITOR  serves  as  the  basic  command  string 
interpreter  of  the  action  files  discussed  previously,  and  acts 
as  the  executive  to  control  functional  interactions  of  all 


subroutines  and  any  tasks.  There  are 

two 

tasks 

that 

execute 

asynchronously  within  MONITOR. 

The 

main 

task 

is  the 

interpreter/ execut ive  program  MONITOR, 

and 

the 

other 

task  is 

called  SYSIN,  for  system  input.  This  latter  task  continually 
monitors  and  seeks  any  input  from  the  connected  system.  In 
fact,  SYSIN  is  an  extension  to  TTERMOP,  doing  all  the  same 
functions  of  TTERMOP,  plus  others  to  be  developed  below. 

The  MONITOR  Task.  In  the  narrowest  focus,  the  program 
MONITOR  reads  the  action  file  selected  by  a  user,  and,  upon 
matching  the  desired  command  name  and  related  command  sequence, 
sends  the  command  sequence  lines  to  the  connected  computer 
system  or  to  the  NOVA/ECLIPSE  RDOS.  In  order  to  interpret  the 
action  file,  the  file  itself  has  to  be  read  into  storage.  The 
simplest  method  to  accomplish  this  is  to  use  FORTRAN  read 
statements  that  store  the  file  in  a  one-dimensional  array,  one 
line  at  a  time.  As  the  action  files  are  exclusively  ASCII,  the 
A  format  specification  is  used  in  the  READ  statements.  As  each 
line  is  read  into  the  array,  the  keywords  or  control  characters 


39 


arc  oxnniincd  to  delc-rminc  further  actions.  Prior  to  takinf'  any 
of  these  further  actions,  tlic  arKowcnts  must  be  resolved. 

A  typical  coumand  instruction  vitliin  the  command  language- 
may  include  no  argunients  or  up  to  four  argunicuts.  Argument 
substitution  then  allows  the  user  flexibility  in  selecting 
arguments  to  be  used  with  any  particular  action  file.  The 
method  of  argument  substitution  developed  is  simple  and  proceeds 
as  follows.  A  command  string  consists  of  a  comr.jaiid  name 
optionally  followed  by  arguments.  Each  argument  of  a  command 
string  is  entered  sequentially  after  the  command  instruction 
name.  The  command  and  arguments  are  separated  either  by  commas 
or  blanks,  where  two  blanks  or  tv;o  commas  together  indicate  a 
null  argument.  Order  must  be  fixed,  and  is  determinid  by  the 
action  file.  An  easy  way  to  identify  the  arguments  in  the 
action  file  is  to  number  them  sequentially,  using  tlic  sharpsign 
as  an  indicator.  For  example,  argument  two  is  denoted  v2  and 
argument  x  is  denoted  #x.  Not  all  command  sequence  instructions 
within  the  action  file  contain  argument  parameters.  In  fact, 
there  arc  certain  sequences  that  may  be  checked,  while  the 
others  may  be  ignored  for  this  purpose.  The  interpreter, 
therefore,  checks  all  command  sequence  instructions  that  are 
preceded  by  the  control  character  set  in  which  the  second 
character  is  either  an  "S"  or  a  "C"  .  In  those  instances,  the 
process  of  argument  substitution  is  four-fold.  First  of  all, 
the  array  containing  the  command  sequence  line  is  checked  to 
determine  if  any  sharpsigns  exist.  If  not,  the  argument 
substitution  process  ceases.  If  a  sharpsign  exists,  the  array 
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the  sharpsign  and  its 


is  collapsed  about  the  sharpsign,  i.c., 
corresponding  nuraber  are  removed  irom  tlie  array.  Next,  in  the 
same  location  where  the  sharpsign  and  iiiiiiiber  v;ere,  the  array  is 
expanded  to  the  size  of  the  argument  entered  by  the  user.  Once 

this  step  is  complete,  spaces  exist  where  the  sharpsign  and 

number  used  to  be.  In  the  last  step  of  th.e  substitution 
procedure,  these  spaces  are  replaced  by  the  argument.  This 

four-fold  process  is  then  repeated  until  all  argument 

placeholders  in  any  particular  command  sequence  line  have  been 
substituted  with  actual  arguments.  Several  error  checking 
procedures  are  in  effect  prior  to  and  throughout  this  process. 
If  an  argument  is  too  long  (ntaxinun  length  40  characters)  or  if 
arguments  supplied  by  the  user  Jo  not  match  exactly  the 
arguments  expected  by  the  action  file,  error  messages  are 

provided  to  the  user. 

Once  arguments  are  resolved  in  any  command  sequence 
instruction,  the  control  characters  dictate  what  action  the 
interpreter  is  to  tal;e  next.  Each  action  is  supported  by  one  or 
more  subroutines  that  program  MONITOR  calls  into  execution.  For 
example,  in  thc‘  command  PUT,  one  of  the  command  sequence 
instructions  is  preceded  by  the  control  character  set  WS.  Upon 
resolving  the  arguments  in  this  instruction,  the  program  MONITOR 
calls  FORTRAN  subroutine  WRITSYSTM  to  implement  the  action  of 
writing  the  instruction  to  the  connected  system.  WRITSYSTM  is 
really  just  a  transition  subroutine  that  smooths  the  transfer 
from  the  FORTRAN  program  MONITOR  to  the  assembly  language 
program  WRSYS,  a  subroutine  called  by  WRITSYSTM.  WRSYS  actually 
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does  tl.r  voik  <.'1  t  I  .ii- •■■.n  1  1 1  i  ii}',  till-  cor.ti.'iiul  insLruction  to  tho 
coniiiclcd  i.  ystin. .  Tlu-  I  r  an  s  ter  is  Eindc  character  by  character. 
Several  otlier  sub  routines  parallel  these  two.  For  a  control 
character  sf  t  of  RW  (read  f  roin  the  local  system  and  write  a 
carriage  return  to  the  connected  system),  the  interpreter  calls 
FORTKA.’,  subroutine  Kl'AI.LV.  K  ITS ,  which  transitions  to  the  assembly 
languap.e  routine  RDAWi;.  For  a  control  character  set  of  WL 
(write  to  the  local  terr;inal),  program  MONITOR  calls  FORTRAN 
subroutine  V’R  I T  LOf'A  I. ,  wliich  does  not  call  any  other  routines. 
The  control  character  set  RR  (ready  the  NOVA/EChlPSE  for  a 
subsequent  read  that  will  take  place),  causes  the  interpreter  to 
call  FORTRAN  subroutine  READYRF.AD.  READYREAD  simply  creates  a 
file  to  bo  used  as  teiiiporary  storage  for  the  information  that 
will  subsequently  be  copied  from  the  connected  system.  Two 
other  control  character  sots  are  similar,  though  converses  of 
each  other.  The  set  WC  (write  a  copy  of  a  NOVA/ECLIPSE  disk 
file  to  the  connected  system)  prompts  program  MONITOR  to  call 
FORTRAN  subroutine  SENDFILE.  SENDFILE  serves  primarily  as  a 
transition  routine  and,  secondarily,  as  a  mini-executive  of  the 
actions  necessary  for  such  a  transfer.  SENDFILE  calls  assembly 
language  subroutines  EXCLI  and  GETFILE.  Program  EXCLI  is  called 
to  execute  the  RDOS  CLI  on  level  tv/o  by  swapping  the  CLI  in  and 
the  program  EXCLI  (or  effectively  MONITOR)  out  of  memory. 
During  the  swap,  the  instruction  contained  in  the 
one-dimensional  action  file  array  (called  lACTFILE)  is  sent  to 
the  RDOS.  Upon  return  from  the  swap,  program  GETFILE  is  called. 
This  program  actually  gets  the  disk  file  that  is  to  be 
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transnittC'd  and  outputs  tlu>  entire  contents  of  the  file 
character  by  character  to  the  connected  system.  The  converse 
of  the  character  sot  WC  is  RC  (road  a  copy  of  a  connected  system 
file  and  store  on  the  NOVA/ECLIPSE).  The  interpreter  responds 
to  the  control  character  set  RC  oy  calling  FORTRAN  subroutine 
RECEVFll.h.  Like  SEliDFlLE,  RECF.VFILE  also  calls  assembly 
language  routine  EXCLI  in  order  to  send  instructions  to  the 
RDOS .  Because  of  the  structure  of  SYSIN,  described  below,  the 
information  from  the  connected  system  has  already  been  received 
and  stored  in  a  temporary  file.  Thus,  execution  of  EXCLI  at 
this  time  simply  transfers  the  input  file  from  this  temporary 
disk  storage  to  the  file  location  input  by  the  user  as  an 
argument . 

The  remaining  programs  called  by  KOKITOR  are  mere  a  part  of 
its  executive  functions,  rather  than  interpretive  functions. 
Two  programs  that  blur  this  distinction  somewhat  are  GETRSPS 
and  CNVKT .  FORTRAN  jirogram  GETRSPS  is  called  by  MONITOR  shortly 
after  initiation,  yet  subsequent  to  user  selection  of  the 
desired  action  file.  This  program  reads  the  action  file 
selected,  looking  for  control  character  I  (mentioned  earlier). 
Entries  in  the  action  file  after  this  character  are  initial 
responses  (up  to  two)  that  may  be  expected  from  the  connected 
system  during  interconnection.  For  example,  in  the  CYBER  action 
file  the  entry  in  the  line  after  control  character  I  is 
"COMMAND-,.."  ,  The  comma  serves  as  a  separator,  indicating  two 
possible  responses  that  may  be  expected  from  the  CYBER  during 
interconnection  with  the  NOVA/ECLIPSE .  The  first  response  is 
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U- "  and  tl)f  ac^cond  response  is  .  GETRSPS  sir.ply 
gets  these  responses,  if  any,  from  the  selected  action  file  and 
stores  them  in  arrays.  Upon  return  from  GETRSPS,  MONITOR 
immediately  calls  asscmhly  language  routine  CNVRT.  The  sole 
function  of  CNVRT  is  to  convert  the  FORTRAN  array  storage  of 
GETliSPS  into  assembly  language  storage.  For  example,  tlie  ASCII 
chaiactcr  "A"  is  stored  in  the  FORTRAN  array  as  tv;o  bytes  in  one 
16  bit  word,  of  wliicli  the  octal  representation  is  <101><40>. 
The  sane  character  is  stored  in  assembly  language  as  <0><101>. 
The  difference  between  these  two  stems  from  the  difference 
between  the  FORTRAN  A  format  specification  used  in  reading  in 
the  array  and  the  assembly  language  construction  that  does  not 
use  special  formating.  In  essence,  the  FORTRAN  road  statement 
puts  a  single  character  into  one  word,  the  left  byte  the  actual 
ASCII  character  code  and  the  right  byte  a  space.  Assembly 
language  looks  at  bytes  only.  Thus,  a  16  bit  word  will  have  a 
null  in  the  left  byte  and  the  actual  ASCII  representation  in  the 
right  byte.  CNVRT  then  stores  the  needed  character 
representation  of  the  responses  and  their  size  in  buffers  that 
are  used  by  subsequent  programs  to  assist  the  interpreter  in 
detecting  responses  from  the  connected  system  and  determining 
whether  or  not  they're  expected. 

Those  programs  that  arc  purely  executive  are  the  programs 
BGIN,  PROMPT,  REVERT,  and  TOTERM.  Each  of  these  carries  out  a 
specific  function  that  needs  to  be  accomplished  to  help 
integrate  the  various  modules  of  MONITOR  into  a  working  whole. 
BGIN  simply  opens  channels  to  the  local  NOVA/ECLIPSE  terminal 
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inpiil 


and  output,  device  codes  —  $TT1  and  i-TTO  ---  respectively. 
PKOllPT  provides  prompt  character  ">"  to  the  user's  terminal 
whenever  called.  The  program  REVKRT  is  selected  by  the  user  as 
an  option  in  lieu  of  a  command  string.  By  entering  the  string 
"*L"  ,  the  user  instructs  the  interpreter  to  return  to  the  RDOS 
CLI.  REVERT  simply  executes  the  return  to  tl;e  CLI.  The  user 
also  has  the  option  of  entering  the  string  "^x"  .  This  string 
instructs  the  interpreter  to  go  to  the  terminal  operation  only 
mode.  In  essence,  the  program  TTPKMOP  is  called,  although  as  a 
subroutine  it  is  slightly  modified  and  renamed  TERMOP.  MONITOR 
actually  calls  TOTERM,  which  first  removes  the  previously 
defined  device  codes  $TT01  and  $TT11,  and  then  calls  TERMOP. 
Appendix  R  contains  a  flowchart  description  of  program  MONITOR 
and  its  v a r  i o us  modules. 

The  Ta  sk .  As  each  of  the  interpretive  and  executive 
functions  of  MONITOR  are  being  executed,  a  separate  task  is  also 
called  into  execution  by  MONITOR.  Using  a  DGC  FORTRAN  version 
task  call,  program  SYSIN  is  activated  at  the  beginning  of 
program  MONITOR.  SYSIN  is  given  a  priority  of  one,  while 
MONITOR  is  automatically  assigned  a  priority  of  zero.  In 
keeping  with  the  RDOS  conventions,  MONITOR  has  the  higher 
priority. 

SYSIN  has  four  basic  actions  to  accomplish.  First,  when 
SYSIN  is  initially  called,  it  identifies  and  defines  the  needed 
device  codes  $TT01  and  $TTI1.  The  remaining  three  actions  occur 
as  the  processor  schedules  the  task  itself.  The  first  action 
taken  by  SYSIN  is  to  continually  check  the  input  buffer  that  may 
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have  been  reccivinj’  data  from  the  connected  system.  Any  data 
received  is  put  into  another  buffer,  called  MATBUFR,  for 
matching  purposes.  Next,  the  program  SVSIN  compares  the  data 
put  into  the  matcli  buffer  with  the  expected  responses  from  the 
connected  system.  (These  responses  v;ere  stored  in  retrievable 
locations  by  program  CKVKT.)  If  the  responses  are  as  expected, 
the  match  buffer  is  cleared  and  new  information  is  entered  into 
it.  If  tlie  responses  are  not  expected,  SYSIN  displays  them  on 
the  NOVA  terminal  for  the  user  to  see.  Finally,  SYSIN  always 
checks  to  see  if  a  temporary  disk  storage  file  has  been  created 
by  the  program  READYREAD.  If  no  such  file  is  created,  then 
SYSIN  does  nothing  extra  and  returns  to  repeal  the  other 
actions.  If  the  file  has  been  created,  however,  then  SYSIN 
writes  the  information  in  the  match  buffer  into  the  temporary 
disk  file  as  well.  Thus,  SYSIN  creates  the  device  interrupt 
routines  for  device  codes/ports  $TT0l  and  $TTI1 ,  monitors  the 
input  buffer,  detects  and  appropriately  displays  responses  from 
the  connected  system,  and  writes  to  a  temporary  disk  file  when 
such  a  file  exists.  Flowcharts  that  describe  SYSIN  are  also 
contained  in  Appendix  B. 

Handshakinp.  Convent  ions .  Because  of  peculiarities  in  the 
RDOS  with  regard  to  its  scheduling  of  user  created  tasks  and 
because  of  the  relatively  slow  response  from  the  connected 
computer  system  (currently  operating  at  300  baud),  several 
handshaking  conventions  available  via  task  calls  have  been 
utilized  throughout  the  program  MONITOR.  Basically,  whenever  an 
instruction  has  been  sent  to  the  connected  computer  system  by 
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any  routine  or  subroutine  of  the  coniniand  language,  the  main  task 
MONITOR  is  suspended.  The  main  task  remains  suspended  until  the 
secondary  task  SYSIN  readies  the  MONITOR.  SYSIN  readies  MONITOR 
after  any  response  from  the  connected  system  or  after  a  built-in 
time  delay  has  been  exceeded.  The  asynchronous  nature  of  the 
two  tasks  is  affected  by  this  implementation,  but  only  after  a 
suspension  of  the  main  task.  Both  tasks  remain  independent  and 
asynchronous  when  both  are  active.  The  handshaking  permits  the 
user  to  control  events  through  the  interpreter,  as  MONITOR  is 
the  task  tliat  the  user  communicates  with.  This  handshaking  and 
the  rel  at  ionsliip  of  all  program.s  that  constitute  the  command 
language  are  presented  graphically  in  Figure  3.  Each  assembly 
language  program  depicted  is  given  the  file  name  extension  .SR, 
while  each  FORTRAN  program  is  given  the  file  name  extension  .FR. 
All  the  programs  shown  in  the  figure  are  loaded  together  and 
executed  under  the  file  name  MONITOR. SV.  The  mechanics  of  the 
loading  and  execution  are  briefly  discussed  in  Appendix  C. 
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REVERT. SR 
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PROMPT. SR 


BGIN.SR 
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^  CNVRT.SR 
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TOTERM.SR 


TEPJIOP.SR 


-  indicates  task  interaction 

-  indicates  subroutine  call  and  return 

■7^ -  indicates  subroutine  call  and  no  return 

Fig  3.  Program  MONITOR  Structure  Chart 
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IV,  Validation 


The  general  purpose  comraand  language  was  constructed  in  a 
modular  manner  from  the  top  down.  The  initial  program  devloped 
and  tested  was  the  main  task  MONITOR.  Until  other  needed 
modules  were  completely  developed,  stubs  were  created  and  used 
to  interact  with  the  main  task.  Tasking  itself  was  not  needed 
and  v.'as  not  introduced  until  the  software  effort  was  fifty 
percent  complete.  The  remainder  of  this  chapter  discuss  the 
testing  and  validation  efforts  with  respect  to  the  c.  .and 
language  development  and  construction.  The  fiist  section 
discusses  efforts  during  the  development,  while  the  second 
section  discusses  efforts  once  a  workable  product  was  p-  "'duced  . 

Puri  ng  Dcvelopnient 

Every  effort  was  made  during  development  to  completely  test 
and  debug  modules  as  they  were  created  and  modified.  Most  of 
the  modules  were  short  and  uncomplicated,  enabling  repeated 
assembling  and  loading  without  extensive  time  delays.  Those 
modules  that  were  more  unwieldly,  such  as  SYSIN  and  MONITOR, 
were  developed  and  tested  in  stages.  A  tool  frequently  used  to 
great  advantage  was  the  DGC  RDOS  Symbolic  Debugger.  The 
debugger  saved  many  manhours  in  tracking  down  sporadically 
appearing  errors.  Perhaps  the  main  feature  of  the  debugger  that 
permitted  this  savings  was  the  ability  to  set  breakpoints  and 
execute  up  to  these  breakpoints. 
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Many  trial  modules  were  created  in  the  project's  beginning 
to  test  system  calls,  FORTRAN  calls,  and  subroutine 
interactions.  A  significant  amount  of  time  was  spent  trying  to 
integrate  FORTRAN  programs  with  assembly  language  programs.  In 
this  regard,  several  small  scale  FORTRAN  programs  and  their 
called  FORTRAN  subroutines  were  created  and  compiled.  The 
NOVA/ ECLIPSE  RDOS  requires  each  distinct  routine  or  subroutine 
to  be  separately  compiled  or  assembled.  Because  of  this, 
compiled  FORTRAN  programs  produce  an  optional  assembly  language 
file.  These  files  were  examined  repeatedly  to  determine  the 
exact  relationship  between  FORTRAN  and  assembly  language 
programs.  Essentially,  the  assembly  language  routines  require 
calls  to  specific  FORTRAN  runtime  library  routines  at  the 
program  beginning  and  end.  These  library  routines  initialize 
variables  and  organize  stacks  automatically,  thereby  enabling 
communication  and  interaction  from  a  FORTRAN  module  to  an 
assembly  language  module.  Another  complication  was  establishing 
the  FORTRAN  address  locations  for  compiler  generated  and 
temporary  variables  within  the  assembly  language  routines. 
This  is  always  accomplished  at  the  end  of  an  assembly  language 
subroutine  by  setting  the  variables  used  in  the  assembly 
language  program  to  FORTRAN  address  locations  expected  by  the 
FORTRAN  main  module.  FORTRAN  calls  to  RDOS  routines  and  system 
calls  within  assembly  language  routines  also  required  repeated 
examination  and  trials  to  determine  their  effects.  Once 
familiar,  those  types  of  calls  proved  quite  powerful  and 
convenient.  It  should  be  noted,  however,  that  complications  can 
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and  did  a  r  i  f-  c  when  mixing  u  s  o  r  defined  operations  that  executed 
in  user  space  with  system  calls  that  executed  in  system  space. 
In  fact,  system  calls  cannot  be  used  at  all  in  user  defined 
interrupt  service  routines.  Finally,  extra  code  was  used 
regularly  to  provide  messages  to  the  user  terminal  regardin.g 
decision  points  encountered  and  overcome.  For  example,  the 
one-d iment ion; 1  array  lACTFILK  that  contained  the  command 
sequence?  instruction  from  Lfic  action  file  was  repeatedly 
displayed  on  the  terminal  screen  throughout  the  argument 
substitution  piocess.  This  provided  clear  and  immediate 
feedback  as  to  the  prograra's  progress  and  correctness  during 
execution. 

No  computer  link  was  available  for  testing  the  interfacing 
programs  until  late  in  the  dovel opmen t ,  nor  v’as  it  needed  until 
late  in  the  development.  Initially,  therefore,  a  simple  line 
printer  was  connected  to  the  input  and  output  ports  of  the 
IIOVA/FCLI PSF, .  Early  programs  were  tested  by  writing  to  this 
printer  and  ignoring  inputs  (since  there  were  none).  About 
halfway  through  the  development,  the  printer  was  replaced  by  a 
separate  terminal.  Later  versions  of  the  interfacing  programs 
provided  for  writing  to  this  terminal  and  reading  from  this 
terminal.  Thus,  two-way  communication  was  established.  The 
program  TTERMOP  was  essentially  proofed  in  this  testing 
configuration,  since  computer  to  computer  dialog  for  this 
program  was  easily  simulated.  Interrupts  were  generated  and 
serviced,  and  responses  were  user-s imul st ed  as  if  the  terminal 
that  was  connected  to  the  access  ports  of  the  NOVA/ECLIPSE  was 
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indeed  the  CYBE)'  computer.  During  this  entire  period  of  time, 
no  mnjor  attempt  was  made  to  streamline  or  enhance  coded 
procedures.  The  first  goal  was  to  make  the  program  execute 
successfully. 

After  De V e 1 opmen t 

Once  the  programs  were  complete  and  individually  tested  in 
the  terminal  to  terminal  environment,  the  emphasis  shifted  to 
integrated  program  validation.  All  independent  aspects  of  the 
individual  modules  were  correctly  compiled,  assembled,  and 
loaded  together  without  any  explicit  errors  discerned  by  the 
RDOS .  By  this  same  time,  all  stubs  had  been  replaced  by  working 
routines  and  the  intial  refinements  had  been  made.  At  this  same 
time,  the  telephone  link  to  the  local  CDC  CYBER  computer  system 
v;as  installed.  Initial  attempts  to  interconnect  the 
nova/eclipse  computers  to  the  CYBER  system  failed  due  to  pin 
mismatches  in  the  RS-232  connectors.  Once  these  pin  connections 
were  changed,  computer  interconnection  was  achieved.  Program 
TTERHOP  worked  well  almost  immediately,  only  requiring 
modifications  that  eliminated  sections  of  code  that  simulated 
modem  functions  for  operation  in  the  terminal  to  terminal  mode . 
Program  MONITOR  had  more  severe  problems,  revolving  around 
handshaking  considerations  for  the  multiple  tasks  in  the  command 
language  interpreter.  These  problems  were  most  difficult  to 
isolate  for  two  reasons.  First,  the  debugger  was  limited  to 
setting  breakpoints  only  within  a  single  task.  That  is,  if 
breakpoints  wore  sot  in  each  task,  the  debugger  would  halt  at 


52 


the  first  brcalcpoint  encountered  in  either  task  and  would 
remain  in  that  task.  The  other  task  was  not  visible  through 
the  debugger  in  this  instance.  The  second  reason  quickly 
overshadowed  the  first  reason.  The  debugger,  and  in  fact  the 
entire  MONITOR  program  would  not  execute  at  all  once  the  entire 
program  was  loaded  together.  The  debugger  and  all  other 
programs  loaded  without  error,  but  a  FORTRAN  runtime  error 
indicating  a  stack  overflow  resulted  whenever  an  attempt  was 
made  to  execute  the  complete  program.  It  appears  that  resident 
memory  is  too  small  to  handle  the  execution  of  the  integrated 
program  with  the  debugger.  Nonetheless,  the  handshaking 
problems  were  corrected  by  using  task  calls  to  appropriately 
suspend  and  ready  the  main  task,  which  allowed  the  secondary 
task  to  seize  control  of  the  processor  as  desired. 

Repeated  failure  of  the  program  SYSIN  to  suppress  displays 
of  expected  responses  from  the  CYBER  computer  system  lead  to  the 
discovery  of  another  problem.  The  CYBER  terminal  sends  out 
sequences  of  null  characters  at  various  times.  These  nulls  are 
accepted  in  the  input  buffer,  but  are  not  visible  to  the 
terminal  user.  Even  so,  they  cause  the  matching  routine  of 
SYSIN  to  give  erroneous  results.  The  solution  is  simply  to 
discard  all  nulls  received  by  the  NOVA/ECLIPSE.  This  corrected 
the  problem  of  detecting  and  suppressing  expected  responses  from 
the  connected  CYBER  system. 

Early  attempts  to  execute  commands  of  the  developed  command 
language  were  intermittently  successful.  Numerous  minor  changes 
were  made  to  the  action  files  to  correct  command  sequences. 


53 


syntax,  and  spacinj^.  To  save  some  time  and  preclude  potential 
problems,  the  interpreter  was  modified  so  as  to  send  only  the 
exact  number  of  characters  comprising  a  command  instruction. 
Prior  to  this  modification,  an  entire  record  line  of  80 
characters  was  sent,  even  if  the  command  string  was  less  tlian  80 
characters.  As  these  changes  were  made,  the  program  became 
progressively  more  reliable. 

File  transfers  have  been  accomplished  and  the  files  have 
been  checked  for  completeness  and  uniformity.  Files  are 
transferred  as  expected  with  one  exception.  Files  received 
from  the  CI)C  CYBER  system  have  an  extra  carriage  return  attached 
at  the  file  beginning  and  end.  These  can  easily  bo  removed 
using  the  text  editor.  Also,  there  were  occcssions  when  a  file 
would  be  transmitted  to  the  CYBER  system  from  the  h’OVA/ECLIPSE, 
but  upon  completion  of  the  transmission,  the  KOVA  computer  would 
hang  up  about  location  12  (octal).  The  problem  v/as 
intermittent,  and  could  not  always  be  duplicated.  Nevertheless, 
files  with  less  than  20  bytes  of  information  and  files  with 
upwards  of  35,000  bytes  of  information  have  been  successfully 
and  repeatedly  transferred  both  v/ays  without  program  failure. 
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V. 


J  t  .ion  s 

A  j;cnpi;il  pnrpo.sc  cormiand  1  a n n, n a p f  for  computer  to  computer 
dialoi^  has  been  dusigupcl,  developed,  and  implemented.  The 
coi'.mand  language,  called  MOI.'ITOK,  meet;;  tbe  basic  constraints 
that  were  established  when  the  problem  was  defined.  The 
pr(>grat.'.  is  flexible,  which  allows  tin  sai.ic  .software  to  be  used 
for  more  than  one  connected  coiiputcr  systci.i  to  the  NOVA/ HCL I  PS  F, 
computers  .  Howevtr,  until  anollu'r  syst<u,i  other  than  the  CDC 
CYBER  is  actually  interconnected  and  u.scd,  the  degree  of 
flexibility  is  a pe cu 1 e t iv e  and  subjective.  The  command 
language  is  general,  to  the  degree  that  it  seems  reasonable  to 
be  able  to  implement  I'OEITOK  on  another  system  other  than  the 
NOVA/ECLIPSE ,  with  some  modifications.  The  assembly  language 
routines  must  be  fitted  to  the  assembler  to  be  used,  and  the 
interaction  between  the  EORTkAN  and  tbe  assembly  language 
routines  may  require  changt'S,  Only  a  test  will  demonstrate  the 
real  generality  of  this  programming.  The  concept  and  overall 
structure  ,  hov.-evir,  seem  mc.st  feasible.  The  interpreter  is  the 
basic  entity  and  should  remain  static  in  most  cases.  The  action 
files  are  system  dependent,  and  they  are  dynamic  by  design. 
Thus,  the  remainder  of  this  cliapttr  will  cover  the  conclusions 
and  recommen  iat ions  regarding  this  project. 
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rone lus ions 


The  general  purpose  command  language  works  well  overall. 
There  are  a  variety  of  available  commands  and  all  have  been 
successfully  implemented.  ASCII  files  have  been  transferred  to 
and  from  the  NOVA/ECLIPSE  repeatedly,  files  have  been  printed 
on  the  CYBER  printer,  and  files  have  been  punched  on  the  CYBER 
punch . 

The  command  language  is  easy  to  use,  simply  defined,  and 
brief.  There  are  just  a  few  commands,  although  more  can  be 
added  or  deleted.  With  these  limited  commands,  much  work  can  be 
accomplished.  The  user  need  enter  a  limited  number  of  words 
only,  and  is  relieved  of  the  tedium  of  repeated  entries.  Fewer 
commands  encourage  use;  simple  commands  encourage  use. 


The 

command 

langua 

ge  is 

not 

as  universal 

as  conceivable. 

Commands 

are  str 

uctured 

to  fit 

the 

environment 

in  which  they 

are  to  be 

used , 

1 imit ing 

their 

universality  somewhat.  Commands 

are  restricted  to  size,  the  number  of  arguments  possible,  and 
the  order  and  position  of  arguments  are  fixed. 

The  program  is  relatively  slow  executing.  Much  of  this  is 
due  to  the  handshaking  that  has  been  used. 

The  program  is  not  as  efficient  as  it  could  be  with  some 
design  changes.  The  handshaking  has  circumvented  the 
independence  and  asynchronization  of  some  of  the  multitasking 
features  of  the  operating  system.  Swapping  takes  place  although 
some  other  means  to  avoid  swapping  may  exist. 
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Finally,  tin-  prop. rams  are  structured  inodularly,  lendinp  to 


ease  of  m o d i f i c a  L i o n ,  readability,  and  u n d e r  s  t  a n d i n p . 


R  e  c  QT-ir: e  ri  d  a  t  i  on  : 

The  following  recommendations  are  presented  to  indicaj 
areas  in  which  the  general  pupose  command  language  u  c  t  e  d 

may  be  improved  and  enhanced.  Some  of  tlup^>*?'ccommLndal  ions 
follow  logically  from  the  cone  1  us  ion s^pTesen t ed  above.  Other 
recoramendat  ions  aie  just  obscrvaJ,>(?ns  and  suggestions  that  have 
accumulated  over  the  tin>>^f  the  project.  Each  r  pcommendat  ion 
is  presented  i n^^^tdi^.-^o p e  that  it  will  either  lead  to  follot.'-on 
project  op_o.«»ft  un  it  ier,  or  a  better  understanding  of  the  project 
a  s  1  e  . 

The  current  structure  and  content  of  the  general  purpose 
language  is  not  necessarily  the  most  efficient  nor  the  most 
effective.  There  are  several  assembly  language  routines  that 
might  readily  be  convertible  to  FORTRAN,  and  several  features 
that  have  been  implemented  might  be  simplified.  logical 
candidates  for  simplification  are  the  routines  EXCLI  and  SYSIN. 
There  may  be  a  more  straightforward  way  to  interact  with  the 
RDOS  from  the  command  language  itself,  for  example. 

Much  more  flexibility  could  be  built  into  the  cci'mand 
language  with  respect  to  the  functioning  of  commands.  For 
example,  the  commands  need  not  be  limited  to  simple  command 
strings.  Perhaps  global  and  local  switches  could  be  introduced 
to  increase  the  power  of  the  command  instructions  tliemselves. 
Further,  argument  defaults  and  optional  arguments  would 
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iiupruvc  the  pover  of  the  lanj^uago. 

The  current  Eoftwr.re  has  no  convenient  means  to  internally 
adapt  to  connected  systems  tliat  arc  full-duplex.  All  the  source 
code  has  been  vrittc'ii  vith  a  half-duplex  link  in  mind.  An 
internal  flag  or  switch  to  appropriately  select  code  for  either 
half-duplex  or  full-duplex  operation  would  certainly  increase 
t 'll c  universality  of  the  software. 

Current  implenentat ion  of  the  MONITOR  command  language  is 
limited  to  ASCII  file  transfers  only.  Expanding  the  capability 
to  lia n d  1  c  binary  files  would  be*  m o .s t  useful,  especially  in 
support  of  tlie  digital  signal  processing  demands. 

With  the  language  implemented  as  it  is,  access  is  now 
available  to  another  computer  system  for  dialog  from  the 
NOVA/ ECLIPSE .  Dovi.'ing  a  method  of  access  to  the  NOVA/ECLIPSE 
from  the  other  computer  system  would  open  new  avenues  of  dialog 
between  computcr.s. 

More  sophisticated  command  languages  often  implement 
pipelining,  i.e.,  stringing  command  instructions  sequentially 
for  sequential  execution.  Implementing  pipelining  within 
MONITOR  would  provide  a  terse  language  of  greater  power  and 
convenience  . 

MONITOR  lends  itself  to  coding  in  a  high-level  structured 
language.  Several  advantages  may  be  gained  by  redesigning 
MONITOR  in  PASCAL,  for  example.  Data  structure  and  file 
structure  manipulations  miglit  be  greatly  simplified  and 
facilitate  greater  creativity  in  developing  command  sequences. 
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1  .  Int  rodiict  ion 

Program  MONITOR  is  a  general  purpose  command  language  that 
may  be  used  for  computer  to  computer  dialog.  The  MONITOR 
softv/are  resides  vithin  the  Data  General  Corporation  (DGC) 
NOVA/KCLIPSE  computer  system.  By  calling  upon  particularly 
designed  action  files,  MONITOR  enables  a  user  to 
int  er  c  om.mun  i  c  a  t  e  with  various  computer  systems  that  are  linked 
to  the  NOVA/ECLIPSE  via  a  standard  RS-232  modem  connection.  The 
input/outpuL  ports  for  the  NOVA/ECLIPSE  are  called  device  codes 
$TT11  and  $TT01 ,  respectively.  These  ports  are  on  the  NOVA  2/10 
computer  only.  However,  since  the  NOVA  2/10  and  ECLIPSE  S/250 
share  a  ten  megabyte  disk  via  the  DGC  Real-Time  Disk  Operating 
System  (RDOS),  access  to  the  ECLIPSE  may  also  be  gained  through 
the  NOVA  by  appropriate  operating  system  instructions. 

The  user  desiring  to  utilize  MONITOR  may  use  a  NOVA  video 
display  terminal  within  the  Air  Force  Institute  of  Technology 
(AFIT)  Electrical  Engineering  department's  Digital  Signal 
Processing  Laboratory.  This  user  manual  will  describe  the 
access  procedures,  the  commands  available  for  use,  the  errors 
that  may  be  encountered,  and  the  particular  design  of  an  action 
file. 

Though  the  command  language  MONITOR  was  designed  to  be  used 
with  different  connected  computer  systems,  only  the  locally 
accessible  Control  Data  Corporation  (CDC)  CYBER  computer  system 
has  actually  been  interconnected.  Thus,  all  examples  and 
specifics  will  refer  to  this  interconnection  throughout  the 
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manu;!l.  A  general  extension  to  other  computer  systems  is 
relatively  straightforv/ard. 
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2  .  H  ow  Arcoss/Urc  HON'  IT  OR 

The  executable  software  package  that  enables  computer  to 
computer  dialog  via  the  NOVA/ F.CLIPSE  computers  is  the  binary 
save  file  MONITOR. SV.  This  file  is  composed  of  several  FORTRAN 
language  and  assembly  language  source  routines  that  arc  loaded 
together  to  form  MONITOR. SV.  The  main  partition  of  the  entire 
software  package  is  the  FORTRAN  source  program  MONITOR. FR,  which 
forms  the  basic  command  language  interpreter  and  executive  for 
the  commarid  language.  (Unless  otherwise  stated  hereafterj  the 
term  MONITOR  will  refer  to  the  binary  save  file  MONITOR. SV.) 

The  software  for  MONITOR  resides  upon  the  NOVA/ ECLIPS F. 
disk,  specifically  the  NOVA  disk  platter.  The  directory  under 
which  MONITOR  is  stored  is  named  DIALOG.  Therefore,  to  access 
MONITOR,  the  user  must  enter  the  directory  DIALOG.  The 
appropriate  command  by  which  to  enter  the  directory  from  any 
other  directory  is: 

DIR  DPOF: DIALOG 

Once  the  user  has  entered  the  directory  DIALOG,  the  user  is 
ready  to  execute  the  command  language.  The  simple  entry 

MONITOR 

will  call  the  binary  save  file  MONITOR. SV  into  execution.  The 
user  will  next  see  the  following  display  upon  the  terminal 
screen : 
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The  MdhITCM’  proj'.ram  you  have  fiUered  provides; 
i  ut  e  r  c  or.ir-.un  i  c  a  t  i  on  between  ihi'  NOV/./ K  hi.  IPS  i:  coi.iputer 
system  and  your  clioice  of  another  system. 


Please  enter  the  dip it  opposite  the  action  file 
you  d e  f.  i  r  c  to  use: 

1  —  CDC  CYBEPv 

2  --  DKC  10 

3  —  VAX  11/780 

4  —  Your  own 


Tl.e  character  ">"  is  a  prompt  that  signals  the  user  to  make  an 
entry.  In  the  above  instance,  an  entry  of  1  would  select  the 
CDC  CYDER  action  file,  a  2  the  DEC  10  action  file,  a  3  the  VAX 
11/780  action  file,  and  a  4  an  action  file  developed  and  coded 
by  the  user.  (Originally,  only  the  CDC  CYBER  action  file  was 
developed.  Thus,  the  other  action  files  existed,  but  had  no 
useful  entries.  Effectively,  these  other  files  contained  no 
commands  and  always  returned  an  error  condition  if  commands  were 
attempted  from  them.)  Entry  of  a  number  other  than  those 
indicated  causes  an  error  message  as  follows; 


You  have  entered  an  illegal  number.  Try  again! 

> 

The  user  is  again  at  the  initial  starting  point. 

Once  the  user  has  entered  a  selected  integer,  such  as  1, 
the  following  type  of  message  is  displayed: 
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Yoli  have  sc'lectc'd  tlio  CYBKR. 

Thank  you.  Pleaue  enter  a  command. 

> 

At  this  point,  all  prel  iniii>ary  initializations  of  the  program 
have  taken  place.  The  user  is  nov/  ready  to  enter  a  specific 
coiiitnand  from  the  available  commands  contained  within  the 
selected  action  file,  or  two  additional  commands  not  contained 
within  the  action  file. 

The  two  commands  not  contained  within  any  action  file  are  a 
command  that  reverts  the  user  back  to  the  RDOS  Command  Language 
Interpreter  (CLT)  and  a  command  that  calls  the  terminal  only 
mode  of  operation  —  program  TEIUIOP  --  into  execution.  The  two 
commands  are; 

'’L  -  revert  to  local  CLI 

^T  -  change  to  teri)\inal  only  mode 

The  next  display  a  user  sees  upon  entry  of  "'L  is: 

You  have  returned  to  the  local  CLI  mode. 

R 

The  "R"  is  the  RDOS  CLI  prompt.  The  next  display  a  user  sees 
upon  entry  of  ^T  is: 

You  have  entered  into  the  terminal  only  mode.  Proceed! 

The  user's  terminal  is  now  connected  as  a  transparent  torL'inal 
to  the  computer  system  selected,  such  as  the  CYBER.  To  exit 
this  mode  and  return  to  the  MONITOR  mode  requires  the  user  to 
enter  an  up-arrow  which  returns  the  user  to  the  RDOS  CLI, 

and  then  to  enter  MONITOR  and  repeat  the  sequences  described 
above . 
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All  other  permissible  entries  are  contained  in  the  action 
file.  To  see  a  complete  list  of  these  commands,  see  the  action 
file  itself.  The  next  chapter  describes  the  original  commands 
developed  and  implemented  within  the  CDC  CYBER  action  file.  As 
action  files  are  designed  to  change,  however,  the  user  must  look 
at  ttie  current  action  file  to  find  the  current  status  of 
c omraand  s  . 
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3  .  0  r  i  R  i  1'  1  Cor-xin  ri  d  s  Av  ,-'.i  1  able 

The  original  conanaiuis  developed  specifically  for  the  CDC 
CYBER  action  file  are  listed  and  briefly  described  below.  These 
conmands  (nairies)  may  be  used  in  other  action  files,  provided 
command  sequences  contained  in  the  action  files  are 
appropriately  designed  and  controlled.  See  Chapter  5  for  a 
discussion  of  the  design  and  structure  of  a  particular  action 
file. 


i’UT.LFN  ,  SFK,  ID  ,  SI'PASSWRD 

This  command  selects  a  local  file  name  (Ll'M)  from  the 
NOVA/ECM PSE  disk  and  transfers  the  file  to  the  connected 
computer  system.  The  transferred  file  is  stored 
permanently  under  a  system  file  name  (SFN)  with  an 
identification  (ID)  aiid  system  file  password  ( SFPASSWRD) 
supplied  by  the  user. 


G ET  ,  S F N  ,  I D ,  S  F  P A  S  S W  RI.1 ,  L FH 

This  cor.rnand  selects  a  SFN  stored  on  the  connected  computer 
system  and  transfers  the  file  to  the  NOVA/ECLIPSE  disk  \7ith 
the  LF’N  input.  The  user  supplies  the  ID  and  SFPASSWRD  for 
the  SFN. 


SPRINT, SFN, SFPASSWRD 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  on 
the  connected  computer  system  and  prints  the  file  out  on 
the  connected  system  printer. 

SPUNCH , SFN, SFPASSWRD 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  on 
the  connected  computer  system  and  punches  the  file  out  in 
Hollerith  code  on  the  system  card  punch. 
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D  E 1. 1' T  E  ,  S  F  M  ,  S  F  1>  A  S  S  W  R  D 


This  command  dcletos/p urges  the  permanent  file  on  the 
connected  computer  system  v/ith  the  SFN  and  SFPASSWRD  input. 


FILES 


This  command  causes  the  connected  system  to  display  local 
files  in  use. 


PFILES 

This  command  causes  the  connected  system  to  display  the 
permanent  files  in  use  for  the  ID  supplied. 

LOGON,  USER  ID,  USER  PASSV.'RD 

This  command  initiates  access  to  the  connected  system.  The 
user  must  supply  the  specific  ID  and  protected  password 
(USER  PASSWRD). 


LOGOFF 

This  command  terminates  access  to  the  connected  system. 


LPRIRT.LFN 

This  command  selects  the  N  on  Lne  NOVA/ECLIPSE  and  prints 
the  file  out  on  the  connected  system  printer. 


LPUNCH.LFN 

This  command  selects  the  LFN  on  the  NOVA/ECEIPSE  and 
punches  the  file  out  in  Hollerith  code  on  the  connected 
system  card  punch. 


SBATCH, SFN, SFPASSWRD, DISPOSITION, TERMINAL  ID 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  for 
execution  on  the  connected  system  in  the  batch  mode.  The 
output  of  the  file  (DISPOSITION)  and  location  (TERMINAL  ID) 
are  supplied  by  the  user. 
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LKATCH , LFN , UI SPOS ITION , TERMINAL  ID 

This  coninand  selects  the  LI’N  on  the  NCVA/ECLIPSE  for 
execution  on  the  connected  system  in  the  batch  mode.  The 
DISPOSITION  and  TERMINAL  ID  arc  supplied  by  the  user. 
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4.  Hrjc^x 

There  are  four  j,eneral  types  of  errors  that  may  occur  in 
execution  of  tlic  program  MOKITOR.  There  are  (a)  interpreter 
errors,  (b)  executive  function  errors,  (c)  ROVA/f^CLIPSE  RDOS 
errors,  and  (d)  connected  coniputer  system  errors.  The  first  tv;o 
types  are  errors  that  arise  within  the  HOh'ITOR  software  itself. 
NOVA/ E CL  1 1’S E  RDOS  errors  occur  v;hencvcr  the  RDOS  generates  an 
error  condition,  and  the  last  type  of  errors  results  from 
operating  system  error  conditions  generated  by  the  connected 
computer  system. 

Connected  Com  nut  or  System  •  NON’ITOK  was  designed  to 
display  error  conditions  generated  by  tlie  connected  computer 
system  to  the  user.  Each  action  file  rc’scrves  a  location  after 
the  control  character  "I"  for  up  to  two  expected  responses  from 
the  connected  system.  Any  response  not  matching  these  expected 
responses  is  displayed  to  the  user.  Thus,  any  erior  conditions 
of  the  coniiecte<I  computer  system  are  simply  passed  to  the  user 
for  action.  I'ost  of  those  error  conditions  are  non-fatal  and 
do  nr*-  cause  NONITdR  to  fail.  Hov/ever,  unexpected  results  may 
arise  if  error  conditions  are  encountered. 

NQVA/ECl.T  rSR  RDOS  ILrjror^.  MONITOR  executes  within  the 
direct  control  of  the  RDOS.  Error  conditions  generated  by  the 
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iTror  cuiulition  and  a  r  c  iiirm  1  a  t  or  valiiGs.  The  T.DOS  P,  e  f  e  r  c  n  c  e 
Manual  (Pcf  9:F--1  -  K-2)  details  these  circumstances.  In  a  less 
severe,  but  fatal  error  condition,  the  HDDS  will  halt  execution 
vithout  a  "panic."  Generally,  a  "Control  A"  input  will  restore 
the  CLl  to  the  user.  On  ether  occasions,  "Control  A"  will  have 
no  effect.  In  these  circumstances,  the  user  must  reset  the 
conpiitfr  and  bring  it  uj)  as  if  it  had  beeti  powered  down.  In  the 
best  case,  the  HDOS  error  condition  will  cause  an  automatic 
return  to  the  RDoS  Cl,  I  and  the  error  condrtion  \.'ill  be  displayed 
to  the  user.  In  any  case,  RDOS  error  conditions  are  generally 
symptomatic  of  software  errors  in  the  executing  program.  All 
such  error  conditions  should  be  examined  and  tracked  in  order  to 
correct  apparent  e r r (' r s  in  the  source  code. 

MON  T  TOR  f_xiicjj_t  j.y_e  Function  Errors .  Executive  function 
errors  are  closely  related  to  NOVA/ ECLIPSE  errors.  In  fact, 
these  errors  are  produced  by  the  RDOS,  but  arc  generally 
anticipated.  Thus,  such  errors  are  caught  by  the  MONITOR 
program  and  serviced  automatically,  or  a  specific  error- 
condition  causes  a  software  halt  of  the  program.  For  exai.iple, 
wheneviT  a  FORTRAN  call  to  open  a  file  is  executed,  a  potential 
error  may  occur  that  indicates  that  the  file  is  already  open  or 
that  such  a  file  doesn't  exist.  MONITOR  handles  all  of  these 
types  of  errors  by  executing  a  STOP  and  displaying  the  cause  of 
the  stop.  Specifically,  if  the  CYBER  action  file  would  not  open 
properly  when  a  call  was  issued  to  open  it,  the  following 
message  would  be  displayed  for  the  user: 
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S'JCI’ 


CACT  NOT  ol’NNED  i’i;ori:i; J, Y 


Other  executive  function  errors  are  handled  identically.  In 
each  instance,  the  cause  nu-st  be  isolated  before  program  MOKIlOil 
can  he  executed  s u c e e s s J u 1 1 y  . 

ZJX.'lVA- •  interj.-retcr  errors  are 
those  tliat  tl'.e  interpreter  IIOH ITOI!  .  FR  anticipates  and  handles. 
Th.ese  errors  art  handled  entirely  cjithin  the  MONITOR  softuaic  . 
Whenever  such  a.s  error  occurs,  the  user  is  notified  via 
display,  and  a  prompt  is  given  to  indicate  that  a  connected 
input  is  needed.  Fach  of  the  anticipated  error  condition.s  and 
their  reasons  are  provided  In- low: 

INVALID  COMMAND  -■  EMPTY  STRING 

Indicates  that  a  comr-.and  string  is  comprised  cf  all  blanks 
or  nulls.  (Entering  a  carriap.c  return  alone  will  result  ri'i 
this  error  condition.) 


SYNTAX  ERROR 

FIRST  OR  LAST  LITERAL  INVALID  SEPARATOR 

Indicates  .a  coinnand  string  began  w'ith  a  comma  and/or  ended 
v/ith  a  co:;,r;’a.  (Only  coiiitnas  and  spaces  are  separators. 
However,  co:r,m.as  cannot  start  or  end  a  cominand  string. 
Spaces  are  ignored  except  between  ot'uer  literals.  Thus,  an 
entry  of  a  coi.imaud  string  that  ends  with  a  coiima  and  then  a 
spate  will  result  in  t  h  i error  condition.  NOTE:  Internal 

null  a  r  g,  ui.ii'U  t  s  within  a  command  string  arc  allowed.  For 

ex  amp  1 e  , 

PUT,, THIS  , THERE 

will  be  accepted  as  a  valid  string  with  the  command  PUT  and 
four  a  r  g  ur:;nn  t  s  .  ) 

INVALID  COILMAND  -  TOO  ELW  CHARACTERS 

Indicates  a  ciinnand  string  with  just  one  character.  Again, 
spaces  are  ignored  except  between  other  literals. 
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Vhr 

1  lid  i  '  (  . 

!.  i  II  ! .  i 


'.(lur  r  f',  union  t  s  .  This 
Will-  Muppliod  with  a 


iKVAhiii  tii:';:;.;:)'  - 


Kach  roiii.iiid  uimI  t, .ir.ii.triL  i'o  up  to  30  chnractorr 

louj;.  Tills  i  r.d  i  0  a  1. 1  a  oiaui.aini  or  a  i  j;  u  m  o  n  U  ontorecj  v/as  31 
or  ITU ir  I  c  h  a  r  a  c  t  o  r  s  . 


IKVATin  COlTAhD 

co.’uiAKD  h'oT  i::  actj''-!;  fji.e 

OR  supPLir;)  :;oT  rqi'al  ki:quiri:d  arcu:ie:;t3 

Indicate:;  one  of  two  po;.f- ibil  itics  :  (1)  tliere  vise  not  a 

match  of  the  c ocr.ia nd  entered  with  any  command  contained 
within  the  action  file.  (could  be  a  ir.i  s>spe  1 1  i.ng .  )  (2)  the 
action  file  coiiinai'd  required  x  a*'”unients  and  either  lesci 
than  X  or  more  tlian  x  arguments  v;er'c  input.  (The  number  of 
arguticnts  must  be  exactly  as  specified  within  the  action 
file.) 


COMMAND  APORT 

UIJKXPKCTKh  ENTRY  IN  ACTION  I'lI.E 

Indicates  an  undefined  or  nonexistent  control  cliaracter  set 
within  a  command  sequence.  (The  action  file  niust  be 
corrected  .  ) 
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5  .  ClXJi'lE.  A.?J  il’-U  Z-i  Le  Pt-  s  )  n 

Tho  basic  structural  design  of  any  action  file  is  detailed 
in  the  main  body  of  this  report.  This  chapter  describes  the 
overall  design  of  action  files  and  details  the  design  of  the 
specific  CYBER  action  file  developed  and  implemented.  The 
listing  of  the  action  file  itself  is  in  Appendix  D. 

Essentially,  the  interpreter  initially  looks  for  the  first 
character  or  first  tv;o  characters  of  each  line  in  the  action 
file.  Depending  upon  these  characters,  action  is  taken  to  read 
th, e  next  line,  stop  reading  the  file,  or  execute  a  line  just 
read.  Thus,  only  specific  characters  arc  expected  in  the  first 
Lv/o  columns  of  the  action  file.  Any  other  characters  are  simply 
ignored.  If  no  recognizable  characters  or  no  characters  at  all 
arc  in  columns  one  or  two,  the  interpreter  cannot  find  any 
useful  ir.f  orraa  t  i  on  and  aborts  reading.  This  feature  docs  allow, 
however,  comments  to  be  inserted  anywhere.  The  character  "C", 
for  example,  is  not  expected  by  the  interpreter.  Thus,  all 
lines  beginning  with  "C"  are  ignored  and  serve  as  comment  lines. 
Any  other  unexpected  character,  such  as  "A",  could  also  have 
been  used,  but  "C"  was  arbitrarily  chosen  to  match  with  FORTRAN 
comment  lines. 

Spacing  is  predetermined  by  the  expectation  of  the 
interpreter  as  well.  The  exact  spacing  established  is 
arbitrary,  but  once  established,  it  must  be  followed  explicitly. 
Thus,  columns  one  and  two  are  reserved  for  control  characters. 
Anything  may  be  in  the  rest  of  a  comment  line.  Lines  that  begin 
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with  "EtJD."  and  "KIKIS)I."  nay  have  eonu.ients  after  then;,  as  the 
interpreter  will  simply  read  the  first  character  and  ignore  the 
remainder  of  the  lino.  Each  comnanJ  sequence  starts  v/i  th  a 
period,  followed  by  the  name  of  a  particular  action  file.  Thus, 
for  the  CDC  CYBER,  each  sequence  starts  with  ".CACT"  .  This 
name  is  folliJv;ed  by  a  specific  command,  as  indicated  in  Chapter 
3.  The  conrn.aiid  is  follov.’cd  by  the  exact  number  of  arguments 
required  in  the  form  of  a  sharpsign  and  an  accompanying  integer. 
Argument  three  is  #3,  for  example.  Each  of  these  entries  must 
be  separated  (arbitrarily)  by  commas.  As  mentioned  in  the  body 
of  this  report,  this  header  line  is  followed  by  executable 
statements  preceded  by  control  character  sets.  The  executable 
s  t  a  t  ei,;en  t  s  must  (arbitrarily)  begin  in  column  nine.  (HOTE:  A  tab 
will  not  suffice  to  separate  the  control  character  sets  from  the 
executable  statements.)  In  each  executable  statement  that 
requires  an  argument,  the  exact  argumeitt  parameter  from  the 
header  statement  must  be  used.  Thus,  if  an  executable  line 
requires  arguirent  three,  the  executable  line  must  contain 
exactly  where  argument  three  is  required.  The  interpreter  will 
substitute  the  arguments  entered  by  the  user  into  the  specified 
locations.  As  noted  before,  each  command  sequence  ends  with  the 
keyv;ord  "END,"  .  and  the  entire  action  file  command  sequence 
ends  with  the  keyword  "FINISH."  . 

All  executable  statements  in  the  action  file  are  sent  to 
the  CYBER  for  execution  if  preceded  by  the  control  character 
set  VIS.  Thus,  these  statements  are  exactly  as  required  by  the 
CDC  CYBER.  Similar  requirements  must  bo  met  for  other  action 
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f  i  1  o  r> .  Ttio  ordor  of  tlicso  sL-iLciaont  s  nuist  nlso  bo  acceptable  to 
the  connected  c.onputcr  system.  If  not  in  the  proper  order  or 
syntactically  incorrect,  the  CYhER  system  will  generate  error 
conditions  and  display  th(>m  to  the  user.  Essentially,  the 
method  of  transferring  files  to  and  from  the  CYBER  utilizes  the 
command  execution  mode  of  the  CYBER  system.  In  this  mode,  the 
CYBER  always  responds  after  correct  user  input  with  "COMI-AKD-"  , 
and  this  is  indicated  in  the  action  file  response  line  --  the 
lino  preceded  by  the  character  "I"  .  Up  to  two  expected 
responses  from  the  connected  system  may  be  in  the  line  after 
the  control  cliaractcr  "I",  beginning  in  column  nine. 
Instructions  entered  in  the  command  sequences  for  PUT,  GET,  and 
similar  command  strings,  simply  tell  the  CYBER  to  copy  all  input 
to  a  file  name  or  copy  all  output  from  a  file  name.  The 
liOVA/ECLlPSE  access  ports,  when  connected  to  the  CYBER,  send  to 
the  input  file  and  receive  from  the  output  file.  To  terminate 
this  copying,  the  command  instruction  %EOF  is  issued.  All  other 
coui.iand  sequences  are  straightforward  and  detailed  in  the  CYBER 
user  documents. 

All  other  executable  statements  not  preceded  by  VJS  tell  the 
KOVA/ECLIPSE  RDOS  to  do  something.  Most  are  straightforward  and 
all  are  explained  within  the  body  of  this  report.  The  lines 
preceded  by  WC  and  RC  contain  executable  statements  for  the  RDOS 
CLI.  For  example,  the  line  containing 

XFER/A  #1  QQVV/R 

is  a  CLI  instruction  to  transfer  the  ASCII  file  named  as 
user-supplied  argument  one  to  the  temporary  disk  file  QQVV ,  and 
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to  rii’.kc:  file  QQVV  a  randora  file. 


Control  character  sets  RC  and 


WC  precede  these  kind  of  executable  lines,  causing  a  swap  to  the 
CLI  to  execute  tlie:'.e  instructions  and  then  a  swap  back  to  the 
main  interpreter  program.  Tbose  lines  that  are  blank,  except 
for  the  control  character  set,  have  no  statements  to  be  executed 
per  so.  The  MONITOR  software  proceeds  strictly  upon  the  basis 
of  the  control  sequence  read.  la  the  case  of  the  set  RR ,  the 
interpreter  creates  a  temporary  file  on  the  MOVA/ FXLIl’SE  disk 
that  v.’ill  be  used  by  a  subsequent  RC  statement.  Hence,  in  order 
for  the  command  sequence  to  execute  properly  from  start  to 
finish,  any  line  with  the  RR  control  character  set  must  be 
fnllov;ed  by  a  line  with  the  RC  control  character  set.  The  RW 
character  set  indicates  that  a  carriage  return  needs  to  be  sent 
to  the  CYDER  to  initiate  access.  This  particular  command 
instruction  is  CYBER  system  dependent,  and  may  require  some 
modification  if  expected  to  be  used  with  another  connected 
computer  system.  The  entry  beginning  in  column  nine  after  the 
control  set  WL  will  be  sent  verbatim  to  the  user  terminal  for 
display.  No  other  control  character  sets  have  been  established 
for  the  interpreter. 

It  should  be  noted  that  the  RDOS  console  interrupts  have 
not  been  deactivated  anywhere  within  the  software  developed. 
Thus,  the  console  interrupts  for  the  RDOS  CLI  are  effective  when 
executed  within  MONITOR.  For  example,  an  entry  by  the  user  that 
is  incorrect  may  be  totally  replaced  by  simply  entering  a 
backslash  "\"  .  The  next  keyboard  entry  will  begin  a  new  line. 
The  backspace  works,  and  the  "Control  A"  and  "Control  C"  inputs 
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work  as  well.  "Control  A"  and  "Control  C"  causn  tlio  cnrrtr.Lly 
executing  prograr.i,  sucli  as  KO,MT(tI<,  to  be  interrupted  and 
control  retr.iiiod  to  the  RDOS  CL  I.  "Control  C"  also  provide-s  a 
"Break"  file  that  displays  a  dump  of  memory  at  the  time  of  the 
interrupt . 

Finally,  the  action  file  for  the  CYBER  has  been  set  up  with 
the  follovting  results.  The  products  produced  upon  the  CYBER 
card  punch  and/or  printer  are  to  be  output  to  the  terminal 
located  in  the  AFTT  School  of  Engineering.  Further,  all 
products  may  be  picked  up  at  the  bin  labeled  "M/N"  ,  since  all 
output  products  will  bo  tagged  v/ith  the  banner  KEO.  The  NOVA 
terminal  identification  number  for  logging  in  purposes  is 
arbitrarily  set  at  777.  Lastly,  the  order  of  the  commands 
entered  into  the  action  file  is  based  upon  use.  Those  comiuands 
used  frequently  arc  placed  in  the  action  file's  beginning, 
whereas  those  used  less  frequently  are  placed  later  in  the 
action  file.  Since  the  interpreter  searches  the  action  file 
sequentially  from  the  beginning  each  time  a  command  is  needed, 
those  used  more  often  will  be  found  in  less  time.  (NOTE:  The 
same  named  command  may  appear  more  than  once  within  an  action 
file.  Tn  order  for  the  interpre'^er  to  distinguish  one  command 
frc'm  anotlier,  in  this  case,  the  number  of  arguments  must  be 
different  for  each  command  name.) 


6  .  S  iiinin  n  t  y 


The  instructions  and  guidelines  contained  within  this  user 
manual  are  the  minimum  needed  to  operate  MONITOR.  Once  a  user 
becomes  familiar  v;ith  the  action  files  and  interpreter,  many 
other  opportunities  may  occur  to  experiment  with  the  program 
MONITOR  that  would  alter  the  guidelines  set  forth  herein.  Such 
changes  arc  expected  and  desirable,  if  this  command  language  is 
to  truly  be  general  purpose.  Furthermore,  there  may  be  areas  in 
which  even  the  basic  structure  of  the  interpreter  may  bo 
profitably  alteroci.  Sec  the  recommendations  covered  in  Chapter 
V  of  the  main  report  for  some  potential  examples.  Finally,  the 
source  listings  and  interactive  guidelines  have  been  developed 
to  provide  the  user  with  necessary  instructions  governing 
MONITOR  execution.  Thus,  a  user  should  be  able  to  use  MONITOR 
quite  readily  v/ith  only  a  listing  of  the  selected  action  file  to 
consult,  once  program  cxcoition  has  begun. 
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Appeni'ix  B 

ProRrnrn  Drsr.r  ipt  ive  TJ.owchart 
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STA){'1' 
HOI!  ITOII 


OPEN  ALL 
ACTION  PILLS 
CALL  Liai! 


CALL  PPO.MPT 


Fig  4.  MON1TOK.fr  (Part  1) 
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Fig  11.  VROMIT.SR 


»D-»100  S19  *19  FORCE  INST  OF  TECH  MtOHT^FATTERSON  *FB  ON  SCHOO~ETC  F/O  »/? 

iEF*«o'^I*0**»MESS**'***'‘  COMNANO  LANOUAK  FO*  USE  IN  C— ETcc 

UNCLASSIFIED  AFIT/KS/EE/80S-tS  „ 


Fig  13.  CNVRT.SR 
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REMOVE 
$TTOl  & 
$TTI1 


I 


c 


— 
CALL 

TERMOP 


3 


Fig  14.  TOTERM.SR 


*  Return  to  a  specified  line  number  (602) 


Fig  15.  WRITSYSTM.fr 
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LOAD 

ELEMENT  OK 
ARRAY 


Fig  16.  WRSYS.SR 


Return  to  a  specified  line  number  (602) 


g  17.  writlocal.fr 


Fig  18.  READLWRITS.fr 


Fig  19.  RDAWR.SR 


Return  to  a  specified  line  number  (602) 


Fig  20.  READYREAD.fr 


9 


*  Return  to  a  specified  line  number  (602) 


Fig  21.  SENDFILE.fr  j 

I 


t 


Fig  22.  EXCLI.SR 


93 


Fig  23.  GETFILE.SR 
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Fig  24.  GETFILE.SR  (Part  2) 
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( 


96 


Fig  26.  TERMOP.SR  (Part  1) 
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COMPARE 
INPTR  TO 
OUTPTR 


Same? 


j  OUTPUT 
CHARACTER 
TO  $TTO 


INCREMENT 

OUTPTR 


/  Outpt>\  Yes  reset 
equal  to  N ^  OUTPTR  TO 
Nmaxptr’/  BEGINNING 


STORE  NEW 
OUTPTR 


Fig  27.  TERMOP.SR  (Part  2) 
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Fig  29.  TERMOP.SR  (Part  4) 


Fig  30.  SYSIN.SR  (Part  1) 
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32.  SYSIN.SR  (Part  3) 
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G 
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Appendix  C 

Load  inp.  and  Execut  inp.  MON  I  TOR 


Each  individual  routine  or  subroutine  created  for  the 
NOVA/F.CLIPSE  must  be  separately  compiled  or  assembled.  In 
accordance  v;ith  the  RDOS  conventions,  all  assembly  language 
routines  have  been  given  the  file  name  extension  “.SR"  .  All 
FORTRAN  routines  have  been  given  the  file  name  extension  ".FR" 
.  For  example,  the  source  code  for  the  main  interpreter  program 
is  named  MONITOR. FR,  and  the  source  code  for  the  separate  task 
program  is  named  SVSIN.SR.  To  assemble  each  assembly  langauge 
source  program,  the  MACRO  assembler  was  used.  A  typical 
instruction  to  cause  assembly  follows: 

MAC  SYS  IN 

The  extension  is  not  needed,  since  the  assembler  automatically 
searches  for  the  file  name  with  the  extension  ".SR"  .  To 
compile  each  FORTRAN  language  source  program,  the  FORTRAN 
compiler  was  used.  A  typical  instruction  to  cause  compiling 
follows  : 

FORT  MONITOR 

The  extension  is  not  needed,  since  the  compiler  automatically 
searches  for  the  file  name  with  the  extension  ".FR"  .  The  local 
switch  "/L"  (slash  and  L)  may  be  used  to  create  a  disk  file  to 
contain  the  assembled/compiled  results. 

The  RDOS  relocatable  loader  was  used  to  load  all  previously 
assembled  and  compiled  programs.  The  first  file  name  listed  in 
the  loader  instruction  sequence  becomes  the  executable  save 
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file.  All  such  files  are  given  the  file  name  extension  ".SV" 

The  local  switch  "/L"  may  be  used  to  create  a  disk  file  to 

contain  the  load  map  of  the  results.  The  following  string 

command  was  used  to  load  all  programs/ sour ces  that  constitute 

the  MONITOR  command  language  interpreter: 

RLDR/P/U  MONITOR  BGIN  PROMPT  REVERT  GETRSPS  CNVRT 
WRITSYSTM  WRSYS  WRITLOCAL  READLWRITS  RDAWR  SEHDFILE  ~ 

EXCLI  GETFILE  READYREAD  RECEVFILE  TOTERM  TERMOP  " 

SYS  IN  FMT.LB  FORT. LB  MIKE5/L 

Once  executed,  file  MINES  contains  the  load  map  and  file 
MONITOR. SV  is  the  executable  binary  file.  The  local  switch  "/P" 
causes  the  normal  relocatable  value  of  each  separate  binary 
file  to  be  printed  out  to  file  MINES,  and  the  switch  "/U"  causes 
a  chain  of  undefined  symbols  to  be  maintained.  File  FORT. LB 
supplies  needed  FORTRAN  runtime  libraries  and  file  FMT.LB 
supplies  the  needed  multitasking  library.  The  order  and 
sequence  of  the  loader  command  is  as  specified  in  the  RDOS 
Reference  Manual  (Ref  9:D-6). 


Appendix  D 

Program  MONITOR  Source  Listinp. 
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C - 

C - 

c 

c  +++++++++++++++++++++++++++ 

c  +  + 

c  +  monitor.fr  + 

c  +  ****  CREATED  30  AUGUST  1980;  REV  01  ****  + 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

C 

C - 

C - 

c 

Q  •kiiic'k'k'k'k-Jc'kic 

c 

C  Program  MONITOR. FR  provides  a  simplified,  general  purpose 

C  Command  Language  for  use  in  computer  to  computer  dialog. 

C  The  host  system  is  a  Data  General  (DG)  NOVA  2/10  that  is 

C  connected  via  a  shared  disk  operating  system  to  a  DG 

C  ECLIPSE  S/250.  Via  a  standard  RS  232  modem  link,  this 

C  program  allows  intercommunication  to  any  compatible  computer 

C  system.  Hereafter,  the  NOVA/ECLIPSE  is  referred  to  as 

C  "local"  and  the  connected  computer  as  "system."  The 

C  program  was  initially  designed  for  intercommunication  with 

C  the  ASD  Control  Data  Corp  CYBER  750  as  the  "system." 

C 

C  MONITOR  serves  as  a  basic  command  string  interpreter.  Upon 

C  execution  of  MONITOR,  the  user  is  provided  instructions  on 

C  hov;  to  access  the  "system"  and  a  prompt  to  enter 

C  commands.  Command  structure  and  use  are  described  in  the 

C  MONITOR  Command  Language  User's  Manual. 

C 

C  "Local"  input  is  received  on  a  "local"  device  channel  -  $TT01 . 

C  "Local"  output  is  transmitted  on  device  channel  -  $TTI1 .  Via 

C  multitasking,  a  task  (SYSIN.SR)  is  always  monitoring  input 

C  while  another  task  (MONITOR. FR)  is  always  conducting  output. 

C  MONITOR  acts  as  the  executive  control  of  these  functions,  in 

C  addition  to  its  role  as  interpreter. 

C 

C  The  structure,  concept,  design,  and  implementation  of  program 

C  MONITOR  and  its  assorted  subroutines  are  detailed  in  the  thesis 

C  that  accompanied  the  development  -  AFIT/GCS/EE/80-2 . 

C 

c 

c - 

c - 
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c 

C  **  Start  the  program  by  defining  tasks,  channels,  parameters,  ** 

C  etc.  CHANTASK  77,2  declares  that  up  to  77  distinct  channel 

C  numbers  may  bo  used  in  the  program  and  that  2  asynchronous 

C  tasks  may  be  executing  "simultaneously." 

C 

CHANTASK  77,2 
C 

C  **  PARAMETER  MDIMl  is  the  size  of  the  one-dimensional  command  ** 

C  instruction  arrays.  MDIM2  is  the  size  of  the  one-dimensional 

C  argument  arrays  and  valid  instruction  string  array.  MDIM3 

C  is  the  size  of  the  one-dimensional  response  arrays. 

C 

PARAMETER  MDIMl  =  82,  MDIM2  =  30,  MDIM3  =  40 

**  SYSIN.SR  is  a  separately-compiled  assembly  language  program  ** 
that  serves  as  the  task  for  monitoring  all  "system"  input. 

DG  FORTP^AN  requires  this  program  to  be  externally  defined  in 
the  calling  program  (MONITOR),  before  it  is  activated  via  a 
call  to  ITASK. 

EXTERNAL  SYS IN 

**  INPUT  is  the  initial  array  store  for  input  commands.  After  ** 
a  determination  of  the  command's  validity,  lACTFILE  is  the 
array  store  for  command  strings  read  from  the  action  file. 

Up  to  four  (4)  arguments  are  possible  with  any  single 
input  command,  and  the  arguments  are  stored  in  the  lARG 
arrays.  Up  to  tv'o  (2)  separate  responses  from  the  "system" 
may  be  provided,  and  they  are  stored  in  the  IRSP  arrays. 

DIMENSION  INPUT(MDIMl) ,  ICOMMAND(lO)IM2) ,  IARG1(MDIM2) 

DIMENSION  IAr;G2(MDIM2) ,  IARG3(MDIM2) ,  IARG4(MDIM2) 

DIMENSION  lACTFILE(MDIHl),  IRSPKMDIMS)  ,  IRSP2(!DI1I3) 

**  Characters  used  for  comparisons  and  decisions  are  data  ** 

initialized.  Therefore,  they  must  be  declared  COMMON 
as  well.  The  data  are  mnemonic.  For  example,  KLTRW  is 
the  letter  "W"  and  KOMMA  is  a  . 

COMMON  /KONST/  KSPACE,  KSLSH,  KOMMA 
COMMON  /KONST/  KUPAROW,  KLTRL,  KLTRT 
COMMON  /KONST/  KNULL,  KPERIOD,  KLTRF 
COMMON  /KONST/  KLTRE,  KLTRC,  KLTRW 
COmON  /KONST/  KLTRR,  KSIIARPSGN  ,KLTRS 
COMMON  /KONST/  KNUMl ,  KNUM2,  KNUID 
COMMON  /KONST/  KNUH4 
C 

DATA  KSPACE, KSLSH, KOMMA/  "<40><40>","<57><40>","<54><40>"/ 

DATA  KUPAROW , KLTRL , KLTRT/  "<136><40>" , "<1 14><40>" , "<124><40>"/ 
DATA  KNULL, KPERIOD, KLTRF/  "<0><40>", "<56><40>" , "<106><40>"/ 

DATA  KLTRE, KLTRC, KLTRW/  "<105><40>","<103><40>","<127><40>"/ 
DATA  KLTRR, KSIIARPSGN, KLTRS/  "<122><40>", "<43><40>", "<123><40>"/ 
DATA  KNUMl ,KNUM2 .KNUIO/  "<61 ><40>", "<62><40>", "<63><40>"/ 

DATA  KNUM4/  "<64><40>"/ 
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C  **  DG  FORTRAN  allows  labels  to  be  tagged.  The  following  are  ** 
C  thus  defined; 

C 

ASSIGN  102  TO  IDOOVER 
ASSIGN  106  TO  IILGNUM 
ASSIGN  108  TO  IlCONT 
ASSIGN  202  TO  IPROHPT 
ASSIGN  206  TO  IEND206 
ASSIGN  304  TO  ISYNERR 
ASSIGN  306  TO  IRMSTOR 
ASSIGN  404  TO  ILMSTOR 
ASSIGN  406  TO  I2CONT 
ASSIGN  412  TO  ICMDSTOR 
ASSIGN  420  TO  IIARGSTOR 
ASSIGN  428  TO  I2ARGSTOR 
ASSIGN  436  TO  I3ARGGTOR 
ASSIGN  444  TO  I4ARGST0R 
ASSIGN  446  TO  ILGTHERR 
ASSIGN  502  TO  lEXAMFIEE 
ASSIGN  506  TO  INOMOENTRY 
ASSIGN  508  TO  ICHKHDR 
ASSIGN  512  TO  I3CONT 
ASSIGN  602  TO  I4C0NT 
ASSIGN  606  TO  lEXECUTE 
ASSIGN  608  TO  ICllKSUBS 
ASSIGN  610  TO  ICONTCHK 
ASSIGN  614  TO  NRHSTOR 
ASSIGN  615  TO  I5C0NT 
ASSIGN  702  TO  ITERMOP 
C 

C  BGIN.SR  opens  channels  21  and  22  for  "local"  input  and  ** 

output . 

CALL  BGIN 

**  The  various  possible  action  files  to  be  interpreted  are  ** 
opened  on  the  channels  indicated. 

CALL  OPEN  (1 ,"CACT",2,IEROR,82) 

IF  (lEROR  .NE.  1)  STOP  CACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (2,"DACT",2,JEROR,82) 

IF  (JEROR  .NE.  1)  STOP  DACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (3,"VACT",2,KEROR,82) 

IF  (KEROR  .NE.  1)  STOP  VACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (4,"MACT",2,LEROR,82) 

IF  (LEROR  .NE.  1)  STOP  MACT  NOT  OPENED  PROPERLY. 


no 


oooo  oooooo  o  o  n  o  oo  o  noo  oooo 


TYPE  "Tlie  >ionitor  program  you  have  entered  provides  " 

TYPE  "intercoiraimnication  betvecn  the  EOVA/ ECLIPSE  computer" 
TYPE  "system  and  your  choice  of  another  system." 

TYPE  "  " 

TYPE  "  " 

C  IDOOVER  =  102 


TYPE 

"Please 

enter  the  digit 

opposite  the 

TYPE 

"you  des 

ire  to  use:  " 

TYPE 

II  II 

TYPE 

It 

1  — 

CDC  CYBER" 

TYPE 

II 

2  — 

DEC  10  " 

TYPE 

II 

3  ~ 

VAX  11/780  " 

TYPE 

ff 

4  ~ 

Your  own  " 

**  Call  the  program  PROMPT  to  signal  the  user  to 
provide  some  kind  of  terminal  entry. 

CALL  PROMPT 

**  Get  the  correct  action  file  requested  Lj  the  user. 

READ  (11,104)  INTRY 
104  FORMAT  (II) 

IF  (INTRY  .I.E.  0  .OR.  INTRY  .GE.  5)  GO  TO  IILGNUM 
GO  TO  (1,2, 3, 4)  INTRY 

IILGNUM  =  106 

106  TYPE  "You  have  entered  an  illegal  number.  Try  again!" 
GO  TO  IDOOVER 

1  TYPE  "You  have  selected  the  CYBER." 

GO  TO  IlCONT 

2  TYPE  "You  have  selected  the  DEC." 

GO  TO  IlCONT 

3  TYPE  "You  have  selected  the  VAX." 

GO  TO  IlCONT 

4  TYPE  "You  have  selected  your  own  file." 

GO  TO  IlCONT 


**  Once  the  desired  action  file  has  been  selected,  GETRSPS.FR  ** 
finds  the  action  file  and  stores  the  responses  to  be  sought 
from  the  "system"  from  this  point  forward. 

IlCONT  =  108 

108  CALL  GETRSPS  ( INTRY, IRSPl , IRSP2,I1SSZ, I2SSZ) 

**  CNVRT.SR  converts  the  characters  stored  in  FORTRAN  format,  ** 
and  found  in  GETRSPS,  to  assembly  language  format.  It 
uses  the  same  arrays  and  also  returns  the  size  of  the 
C  response  arrays. 

C 

CALL  CNVRT  ( IRSPl , IRSP2 , II SSZ , T2SSZ) 
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c 

c - 

c 

C  The  preliminaries  are  over  and  the  program  is  now  ready  ** 

C  for  user  instruction  inputs. 

C 

TYPE  "Thank  you.  Please  enter  a  command." 

C 

C  **  ITASK  activates  task  SYSIN.SP.  v;ith  identity  number  ten  (10)  '-■* 
C  and  priority  one  (1).  Thus,  SYSIH  has  lower  priority  than 

C  the  calling  program  -  HOllITOK.  KOh'ITOR  has  priority  zero  (0)  . 

C 

CALL  ITASK  (  SYS  IN ,  1 0 , 1  ,  IF.R ,  1  ) 

IF  (lER  .NE.  1)  STOP  SYSIN  HOT  ACTIVATED  PROPERLY. 

C 

C  **  Provide  the  user  with  the  proiupt  ">"  .  ** 

C 

C  IPROr.PT  =  202 
202  CALL  PROMPT 
C 

C  After  cacti  access  to  the  action  file,  its  pointer  needs  ** 

C  to  be  reset  to  Llie  file's  beginning.  The  call  to  I'SEEK 

resets  the  pointer  accordingly. 

CALL  ISEEK  (ti;tRY,0) 

**  Road  what  the  user  inputs  and  store  in  INPUT.  Word  entries  ** 
may  be  separated  by  individual  commas  or  single  spaces. 

READ  (11,204)  (IKPUT(I),  1=1,  MDIMl ) 

204  FORMAT  (82A1) 

C 

C  **  Check  to  see  if  user  desires  terminal  only  operation  or  a  ** 
C  return  to  tlie  "local"  command  language  -  CLI .  An  input  of 

C  "~L"  reverts  user  to  the  "local"  CLI.  An  input  of  "''T" 

C  causes  terminal  only  operation. 

C 

DO  206  INDXA  =  1 ,  MDIMl 

IF  (INPUT(INDXA)  .HE.  KUPAROW  .OR.  INDXA  .GE.  MDIMl) 

+  GO  TO  IEND206 

INDXA  =  INDXA  +  1 

IF  (INPUT( INDXA)  .EQ.  KLTRL)  CALL  REVERT 
IF  (INPUT( INDXA)  .EQ.  KLTRT)  GO  TO  ITERMOP 
INDXA  =  INDXA  -  1 

C  IEND206  =  206 
206  CONTINUE 
C 

C - 
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c 

C  Search  array  input  rip.ht  to  left  to  find  the  first  non-null/** 

C  non- blank  character. 

C 

DO  302  Ih'DXB  -  1,  MDim 

IF  (1KPUT((MD1M1  1)  -  IKDXB)  .EO.  KOllliA) 

+  GO  TO  TSYNERIt 

IF  (lKPUT((lIDIt!l  +  1)  -  TKDXB)  .XE.  KKULL  .AND. 

+  INPb"i'((MDlI!l  +  1)  -  IHDXB)  .NE.  KSPACE) 

+  GO  TO  IRMSTOR 

302  CONTINUE 
C 

C  If  none,  so  state  and  return  to  prompt. 

C 

TYPE  "  " 

TYPE  "  INVALID  COIIMAND  -  EMPTY  STRING  ****■;:" 

GO  TO  I PROMPT 
C 

C  If  the  string  ended  with  a  separator  comma,  so  state  ** 

C  and  return  to  the  prompt. 

ISYh'ERR  =  304 
304  TYPE  "  " 

type  "  *****  SYNTAX  ERROR  *****  " 

type  "  *****  FIRST  OR  LAST  LITEPJiL  INVALID  SEPARATOR  *****  " 

GO  TO  IPROMFT 


**  Otherwise,  store  the  index  of  the  rightmost  character, 


IKIISTOR  =  306 

306  IRTlkSTlNDX  =  (HDIMl  +  1)  -  INDXB 


C  ■'■■*  Now  find  the  leftmost  character. 

C 

DO  402  INDXC  =  1,  MDIMl 

IF  (INPUT( INDXC)  .EQ.  KOMMA)  GO  TO  ISYNERR 
IF  (INPUT( INDXC)  .NE.  KSPACE)  GO  TO  ILMSTOR 

402  CONTINUE 
C 

C  **  This  error  return  should  never  be  taken. 

C 

TYPE  "  " 

TYPE  "  *****  INVALID  COHr.AND  -  EMPTY  STRING  *****" 

GO  TO  IPROMPT 
C 

C  **  Discard  initial  blanks/spaces  and  store  it. 

C 

C  ILMSTOR  =  404 

404  LTMOSTINDX  =  INDXC 
C 


113 


o  o  o  o  o  o 


c 

c 


Chock  for  obvious  error  condition. 


•k-k 


IF  (LT;:OSTIhl)X  .KF.  IRTKSTINDX)  GO  TO  12C0!IT 
C 

TYPE  "  " 

type  "  ievALTD  command  -  TOO  FEW  CHARACTERS  " 

CO  TO  I PROMPT 
C 

C  *'-■  Now  senrch  the  input  string  for  the  command  portion,  i.c.,  ** 

C  until  a  sei)arator  or  a  rightmost  character  is  encountered. 

C 

C  I2C0NT  =  A06 

AOb  DO  408  INDXD  =  LTKOSTIKDX,  IRTMSTIIIDX 

IF  (INPI'T(  INDXD)  .EQ.  KSPACF.  .OR.  TNPUT(  1 NDXD )  .EQ. 

4  KOM>!A)  GO  TO  ICMDSTOR 

408  CONTINUi: 

C 

C  **  If  the  string  is  a  single  corsiand,  store  it  in  COlfllAND.  ** 

C  First,  initialize  index  for  the  COIRIAND  array. 

C 

NDIMl  =  (IRTMSTIKDX  -  LTEOSTTl.'DX)  +  1 
IF  (NDINl  .GT.  KD1112)  GO  TO  ILGllIERR 
DO  410  IKDXE  =  1,  NDIMl 

ICOMMANUdNDXE)  =  IKPUT(1NDXR  +  (LTMOSTINDX  -  1)) 

410  CONTINUE 

**  At  each  point  that  the  number  of  arguments  is  deterninod,  ** 
jump  ahead  to  execute  the  cov.’.raand.  In  this  case,  for  example, 
there  is  just  a  command  word  and  no  arguments. 


NUMARGS  =  0 
GO  TO  lEXAMFILE 
C 
C 

C  **  A  separator  was  encountered,  so  there  is  more  than  just  a 
C  single  command.  Store  the  command  portion  and  resolve  the 

C  rest  of  the  string. 

C 

C  ICMDSTOR  =  412 

412  NDIMl  =  INDXD  -  LTMOSTINDX 

IF  (NDIMl  .GT.  MD1M2)  GO  TO  ILGTHERR 
DO  414  INDXF  =  1,  NDIMl 

ICOin-IANDdNDXF)  =  INTUTdNDXF  +  (LTMOSTINDX  -  1)) 

414  CONTINUE 
C 

C  **  Proceed  to  establish  the  value  of  the  first  argument. 

C 

IDXPl  =  INDXD  +  1 

DO  416  INDXG  =  IDXPl  ,  IRTHSTIMDX 

IF  (iNPUTdNDXG)  .EQ.  KSPACE  .OR.  INPUT(INDXG)  .EQ. 
+  KOMMA)  GO  TO  IlARGSTOR 

416  CONTINUE 
C 
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C  **  If  a  single  argument,  process  it. 

C 

NDIM2  IRTMSTinnX  -  IKDXD 
IF  (NDIM2  .GT.  MD1M2)  GO  TO  ILGTHERR 
DO  A18  INDXH  =  1 ,  NDIM2 

lARGl(lKDXll)  =  IDPUTdt.'DXlI  +  INDXD) 

418  CONTiriUE 
C 

c 

KUMARGS  =  1 
GO  TO  lEXAMFlLE 
C 
C 

**  A  separator  was  encountered.  Store  the  first  argument 
portion  and  resolve  the  re.st  of  the  string, 

IIARGSTOR  =  420 

420  NDIM2  =  lEDXG  -  (IKDXD  +  1) 

IF  (NDIi:2  .GT.  MDIM2)  GO  TO  ILGTHERR 
DO  422  IKDXI  =  1,  NDIM2 

lARGl(INDXl)  =  INPUTdKDXI  +  IKDXD) 

422  CONTINUE 

**  Proceed  to  get  the  next  argument  for  array  2. 

IGXPl  =  INDXG  +  1 
DO  424  INDXJ  =  IGXPl ,  IRTMSTINDX 

IF  (INPUTCINDXJ)  .EQ.  KSPACE  .OR.  INPUTdNDXJ)  .EQ. 
+  KOltMA)  GO  TO  I2ARGSTOR 

424  CONTINUE 

**  Just  two  arguments  -  process  the  second. 

NDIM3  =  IRTMSTINDX  -  INDXG 
IF  (NDIM3  .GT.  HDIM2)  GO  TO  ILGTHERR 
DO  426  INDXK  =  1,  NDIH3 

IARG2dNDXK)  =  IKPUTdNDXX  +  INDXG) 

426  CONTINUE 


NUMARGS  =  2 
GO  TO  IEXAMFILE 

**  A  separator  was  encountered.  Store  the  second  argument  ** 
portion  and  resolve  the  rest  of  the  string. 

I2ARGST0R  =  428 

428  NDIIO  =  INDXJ  -  (INDXG  +  1) 

IF  (NDIM3  .GT.  MDIM2)  GO  TO  ILGTHERR 
DO  430  INDXL  =  1,  NDIM3 

IARG2dNDXL)  =  IKPUTdNDXL  +  INDXG) 

430  CONTINUE 
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C  **  Proccdo  to  get  the  next  argument  for  array  3. 

C 

ijxpi  -  it;nxj  +  1 

DO  432  INDXM  =  IJXPl  ,  IRTMSTIN'DX 

IF  (iNPUT(IKDXn)  .F,Q.  KSPACK  .OR.  INPUTCINDXM)  .EQ. 
+  KOIIMA)  00  TO  13ARGST0R 

432  COUTlliUE 
C 

C  **  Just  three  arguments  -  process  the  third, 

C 

ND1M4  =  IRTKSTINDX  -  II’DXJ 
IF  (NDIM4  .GT.  MDIM2)  GO  TO  IIGTIIERR 
DO  434  INDXN  1  ,  ND1H4 

IARC3(1NDXN)  -  Ih'?UT(IKDXh  +  INDXJ) 

434  CONTI HUE 

C 

c 

NUllARGE  =  3 
GO  TO  lEICIMFILE 
C 

c 

C  **  A  separator  vas  encountered.  Store  the  third  argument 
C  and  resolve  the  rest  of  the  string. 

C 

C  I3ARGST0R  =  436 

436  NDIM4  =  INDXM  -  (IKDXJ  +  1) 

IF  (NDIM4  .GT,  1IDIM2)  GO  TO  ILGTHERR 
DO  438  INDXO  -  1,  NDIM4 

IARG3(INDX0)  =  INPUT( INDXO  +  IKDXJ) 

438  CONTINUE 
C 

**  Precede  to  get  the  next  argument  for  array  4. 

IIKFl  INDXH  +  1 
DO  440  INDXP  =  IMXPl,  IRTMSTINDX 

IF  (INPUT(INDXP)  .EQ.  KSPACE  .OR.  INPUT(INDXP)  .EQ. 
+  KOMMA)  GO  TO  I4ARGST0R 

440  CONTINUE 


**  Just  four  arguments  -  process  the  fourth. 

NDIM5  =  IRTMSTINDX  -  IKDXM 
IF  (NDIK5  .GT,  HDIH2)  GO  TO  II.  . 'UERR 
DO  442  INDXQ  =  1,  NDIM5 

IARG4(IKDXQ)  =  INPUT( INDXQ  +  INDXM) 

442  CONTINUE 


NUMARGS  =  4 
GO  TO  lEXAMFILE 
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C  **  A  separator  was  encountered.  There  are  too  many  arguments.  ** 
C  Give  an  error  message  and  return  to  the  prompt. 

C 

C  I4ARGST0R  =  444 
444  TYPE  "  " 

XYPE  "  *****  INVALID  COMMAND  -  TOO  MANY  ARGUMENTS  *****" 

GO  TO  1 PROMPT 
C 

C  I LG TH ERR  =  446 
446  TYPE  "  " 

XYPE  "  *****  INVALID  COMMAND  -  TOO  MANY  CHARACTERS  *****  " 

GO  TO  I PROMPT 


**  Once  a  potentially  valid  command  string  has  been  accepted,  ** 
it  is  time  to  examine  the  action  file  for  that  conmand. 

The  strings  of  the  action  file  are  read  into  lACTFILE. 

lEXAlfFILE  =  502 

502  READ  (INTRY,504)  (lACTFILE(j),  J  =  1,  MDIMl) 

504  FORMAT  (82A1) 

**  Check  the  first  character  of  the  line  just  read.  ** 

If  an  "F",  there  are  no  more  entries  to  read.  If  a 
period,  then  the  encountered  header  line  needs  to  be  checked. 

IF  (lACTFlLE(l)  .EQ.  KLTRF)  CO  TO  INOMOENTRY 
IF  (lACTFILE(l)  .EQ.  KPERIOD)  GO  TO  ICHKHDR 
GO  TO  lEXAMFILE 

INOMOENTRY  =  506 
506  TYPE  "  " 

XYPE  "  *****  INVALID  COMMAND  *****  " 

XYPE  "  *****  COMMAND  NOT  IN  ACTION  FILE  *****  " 

XYPE  "  *****  OR  SUPPLIED  NOT  EQUAL  REQUIRED  ARGUMENTS  *****  " 
GO  TO  IPROMPT 
C 

C  **  All  commands  are  ten  (10)  characters  or  less.  Here,  ** 

C  the  command  portion  of  the  header  is  determined. 

C 

C  ICHKHDR  =  508 

508  DO  510  INDXZ  =  7,  17 

IF  (lACTFILE(lNDXZ)  .EQ.  KSPACE  .OR. 

+  IACTFILEC INDXZ)  .EQ.  KOMMA)  GO  TO  I3CONT 

510  CONTINUE 
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C  **  Compare  the  header  command  to  that  input  by  the  user.  ** 

C  If  correct,  proceed.  Otherwise,  return  to  read  the  action 

C  file  again  until  finished,  or  the  next  header  is  encountered. 

C 

C  I3C0NT  = 

512  INDXY  =  INDXZ  -  7 
C 

IF  (NDIMl  .NE.  INDXY)  GO  TO  lEXAMFILE 
DO  514  INDXX  =  1,  INDXY 

IF  (lACTFIEEC INDXX  +  6)  .NE.  ICOMHAND( INDXX) ) 

+  GO  TO  lEXAMFlLE 

514  CONTINUE 

**  Look  at  the  number  of  required  arguments  for  this  command.  ** 

If  there  are  no  arguments,  then  two  spaces  after  the 
command  string  in  the  header  will  be  a  space.  Similarly, 
if  there  is  one  argument,  five  spaces  after  the  command  string 
in  the  header  will  be  a  space,  and  so  forth.  The  INDX 
numbers  are  the  location  of  the  sharpsigns  in  the  header 
string.  Compare  the  command  string  in  lACTFILE  with  the 
sharpsign  location  to  determine  how  many  arguments  are  required. 

INDXl  =  INDXZ  +  1  ■,The  sharpsign  is  2,5,8, 

INDXZ  =  INDXZ  +  4  ;and  11  spaces  after  command 

INDX3  =  INDXZ  +  7  ; string  -  1,4,7,  or  10  spaces 

INDX4  =  INDXZ  +  10  ; after  comma,  if  arguments  exist 

NNUMARGS  =  4 

IF  (IACTFILE(INDX4)  .EQ.  KSPACE)  HNUmGS  =  3 

IF  (IACTFILE(INDX3)  .EQ.  KSPACE)  NNUMARGS  =  2 

IF  (IACTFILE(INDX2)  .EQ.  KSPACE)  NNUMARGS  =  1 

IF  (IACTFILE( INDXl)  .EQ.  KSPACE)  NNUMARGS  =  0 

**  Compare  the  required  number  of  arguments  with  the  supplied  ** 
number  of  arguments. 

IF  (NUMARGS  .EQ.  NNUMARGS)  GO  TO  I4C0NT 

**  If  the  arguments  supplied  are  not  equal  the  number  required,** 
then  continue  to  examine  the  action  file  for  the  same  named 
command  with  the  appropriate  number  of  arguments.  (NOTE:  This 
means  that  more  than  one  command  with  the  same  name  may  be  entered 
and  found  within  the  action  file,  but  each  must  have  a  different 
number  of  arguments.) 

GO  TO  lEXAMFILE 
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C  **  If  nr '.ui’ic-nt H  roqiiirod  cqn.-il  nr "iiircnt s  supplied,  then  read  ** 

C  tile  next  line  in  the  action  tile,  \/hich  is  the  first  comnand 

C  in  the  coimiand  sequence.  The  last  coi.iuiand  in  the  sequence 

C  precedes  "KNl)."  . 

C 

C  lACOIlT  =  602 

602  Rl'.ADC  IKTKY,604)  ( lACTFIhE(K)  ,  K  =  1,  MDIMl) 

604  FOR!v\T  (82A1) 

C 

C  **  Look  at  the  first  two  control  letters  to  dcterininc  ** 

C  specific  actions  to  take.  If  "KKD."  is  encountered,  the  command 

C  sequence  is  over.  If  an  "S"  or  "C”  is  encountered  in  column 

C  two  (2),  then  the  striiii;  needs  to  be  checked  for  substitution 

C  of  arguments  for  the  sharpsigns  in  the  action  file.  Then  the 

C  remaining  control  letters  are  examined.  Appropriate  subroutines 

C  are  called  to  execute  the  strings  as  required.  Each  subroutine 

C  returns  to  the  place  where  a  new  line  out  of  the  action  file 

C  may  be  read  and  examined.  For  further  discussion  of  control 

C  characters,  look  at  the  action  file  documentation  or  the 

C  MONITOR  Command  Language  User^s  Manual. 

C 

IF  (lACTFILE(I)  .EQ.  KLTRE)  GO  TO  IPROMPT 
IF  (IACTriI.E(2)  .F.Q.  KLTKS  .OR.  IACTF1LE(2)  .EQ.  KLTRC) 

+  CO  TO  ICllKSUKS 
C  lEXECUTE  =  606 

606  IF  (lACTFILEd)  .EQ.  KLTRW  .AND.  IACTFILE(2)  .EQ.  KLTRS) 

+  CALL  WRITSYSTM  ( lACTFILE, HRTMSTIMDX , $602 ) 

IF  (lACTFILEd)  .EQ.  KLTRW  .AND.  IACTF1LE(2)  .EQ.  KLTRL) 

+  CALL  WRITLOCAL  (lACTFILE, MDIIll  ,  $602) 

IF  (lACTFILEd)  .EQ.  KLTRR  .AND.  IACTFILE(2)  .EQ.  KLTRW) 

+  CALL  READLWUITS  ($602) 

IF  (lACTFILEd)  .EQ.  KLTRW  .AND.  IACTFILE(2)  .EQ.  KLTRC) 

+  CALL  SENDFILE  (lAlTFILE, MDIMl ,$602) 

IF  (lACTFILEd)  .F.Q.  KLTRR  .AND.  IACTFILE(2)  .EQ.  KLTRC) 

+  CALL  RECEVFILE  (lACTFILE , MDIMl , $602 ) 

IF  (lACTFILEd)  .EQ.  KLTRR  .AND.  1ACTF1LE(2)  .EQ.  KLTRR) 

+  CALL  READYKEAD  ($602) 

C 

C  **  If  unexpected  letters  are  encountered,  the  action  file  is  ** 

C  suspect.  Abort  and  try  again. 

C 

TYPE  "  " 

TYPE  "  *****  COMMAND  ABORT  *****  " 

TYPE  "  *****  UNEXPECTED  ENTRY  IN  ACTION  FILE  *****  " 

GO  TO  IPROMPT 
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c 

C  Check  for  and  make  any  required  substitutions.  ** 

ICHKSUBS  =  608 
608  IBGIKINDX  =  9 

**  Start  looking  in  column  nine  (9)  for  sharpsigns  to  replace.  ** 
Then  use  new  value  of  IBGIMINDX  on  subsequent  iterations. 

ICOMTCllK  =  610 

610  DO  612  NAIMDX  =  IBGININDX,  MDlMl 

IF  (lACTFlLE(NAIKDX)  .EQ.  KSHARPSGM)  GO  TO  I5C0HT 

612  CONTINUE 

**  There  were  no  sharp  signs  or  there  are  no  more  sharp  signs.  ** 
Now  find  the  rightmost  index  of  the  current  coiiunand  line 
and  return  to  execute  string. 

DO  613  NCINDX  =  1,  MDIKl 

IF  (lACTFILE  ((  MDlMl  +  1)  -  NCINDX)  .KE.  KOTLL  .AND. 

+  lACTFILE  ((  MDlMl  +  1)  -  NCINDX)  .NE.  KSPACE) 

+  GO  TO  NRMSTOR 

613  CONTINUE 

NRMSTOR  =614 

614  NRTMSTINDX  =  (MDlMl  +  1)  -  NCINDX 
C 

GO  TO  lEXECUTE 
C 

C  **  Collapse  the  array  about  the  sharp  signs.  ** 

C 

C  I5C0NT  =  615 

615  NAPllNDX  =  HAINDX  +  1 
NAMllNDX  =  tJAINDX  -  1 

IF  (lACTFILE(NAPlIKDX)  .EQ.  KNUHl)  IVAIOFSGN  =  1 

IF  (lACTFILE(NAPlINDX)  .EQ.  KHUM2)  IVALOFSGN  =  2 

IF  (IACTFILE( NAPllNDX)  .FQ.  KNUM3)  IVALOFSGN  =  3 

IF  (lACTFILE (NAPllNDX)  .EQ.  KNUH4)  IVALOFSGN  =  4 

M2HDIM1  =  MDlMl  -  2 
DO  616  NBINDX  =  NAIMDX,  M2MDIM1 

lACTFILE(NBlNDX)  =  IACTFILE( NBINDX  +2) 

616  CONTINUE 
C 
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C  **  Detcmine  the  size  of  the  arp.uiaont  arr  lys  (lARG)  and  expand  ** 
C  the  coiTTnand  sequence  in  lACTFILE  to  make  room  for  the 

C  substitution  of  the  lARG  arrays,  where  the  corresponding 

C  sharpsigns  had  been.  IVALOFSGN  is  the  value  of  the  particular 

C  sharpsign  being  substituted  with  lARG. 

C 

GO  TO  (618,620,622,624),  IVALOFSGN 
C 

618  ISIZEARG  =  KDIM2 
GO  TO  626 

620  ISIZEARG  =  NDIM3 
GO  TO  626 

622  ISIZEARG  =  NDIM4 
GO  TO  626 

624  ISIZEARG  =  NDIM5 
C 

C  **  Expand  the  array  to  make  room  for  the  substitution  of  lARG. 

C 

626  IRGHTMST  =  MDIMl  -  ISIZEARG 
IR’CRMAX  =  IRGHTMST  -  NAINDX 

lACTFILEdRGllTKST  +  ISIZEARG)  =  IACTF1LE(  IRGHTMST) 

DO  628  Ml  =  1 ,  INCRHAX 

IACTFILEC (IRGHTMST  -  Ml)  +  ISIZEARG)  = 

+  IACTFILE( IRGHTMST  -  Ml) 

628  CONTINUE 


C 

c 

c 

c 


c 


c 


c 


c 


**  Replace  each  sharp  sign  —  #1,  i?2,  #3,  and  #4 

GO  TO  (630,634,638,642),  IVALOFSGN 

630  DO  632  M2  =  1 ,  ISIZEARG 

IACTFILE(NAM1INDX  +  M2)  =  IARG1(M2) 

632  CONTINUE 
GO  TO  646 

634  DO  636  M3  =  1,  ISIZEARG 

IACTFILE(NAM1INDX  +  M3)  =  IARG2(M3) 

636  CONTINUE 
GO  TO  646 

638  DO  640  M4  =  1,  ISIZEARG 

IACTFILE(NAM1INDX  +  M4)  =  IARG3(M4) 

640  CONTINUE 
GO  TO  646 

642  DO  644  H5  =  1 ,  ISIZEARG 

IACTFILE(NAM1INDX  +  M5)  =  IARG4(M5) 

644  CONTINUE 

**  Recalculate  IBGININDX  for  the  next  iteration. 
646  IBGININDX  =  NAINDX  +  ISIZEARG 
GO  TO  ICONTCHK 


if  used. 


** 
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c 

c - 

c 

C  **  Before  going  to  tlie  terminal  operation  mode,  inactivate 
C  (kill)  the  task  SYSIN.  Then  call  the  program  TOTr.RM.SR, 

C  which  removes  defined  device  codes  utilized  within  SYSIU. 

C 

C  IirRMOP  =  702 

702  CALL  AKlLL(l) 

C 

CALL  TOTERM 


C 


** 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


STOP  END  OF  THE  PROGRAM 
END 


+  +  +  +  +  +  +  +  +  4  +  +  +  -I  +  +  4  +  +  +  +  +  +  +  +  1  + 


END  MONITOR.fr 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


122 


+  +  +  +  +  +  +  +  +  ^  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  + 

4- 


+  BGIK.SR  4- 

+  ****  CREATED  3  JULY  1980;  REV  01  ****  4- 

+  + 
4'4-4-4-4-44-4-  +  4-4-4-4-4-  +  4-4-  +  4-4-  +  4-4'4-4-4-4- 


ic'k'k'k  -k  k  k  k  k  k 

Proi^rcm  BGIK.SR  is  called  from  KOHITOR.FR  and  returns  to 
MONITOR.  It  is  called  at  the  beginning  of  the  MONITOR  program 
to  open  devices  $TTO  and  $TT1  for  all  subsequent  programs. 
There  are  no  arguments  or  parameters  that  are  passed  via  BGIN. 

kkkkkkkkkk 


TITL 

BGIN 

; Program  name  -  Begin 

ENT  1 

BGIN 

jEnables  outside  entry  into  this 
; program 

TXTH 

1 

;Packs  ASCII  strings  left  to  right 

EXTU 

;Undefincd  variables  are  treated 
;as  External  Displacement  variables 

EXTN 

.1 

;Provides  some  FORTRAN  initialization 

•NREL  jNormal  relocatable  space  starts 

FS. 
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BEGIN  TO  OPEN  DEVICES 


EGIN  : 
START: 


JSR  0  .FARE 

SUB  1,1 

;Load 

default  mask 

LDA  0,  NTTO 

;  Load 

bytepointcr  to  $T'1'0 

.SYSTM 
.OPEN  21 

jOpCMI 

$TTO  on  channel  21 

JMP  ERROR 

LDA  0,  NTT I 

;Load 

bytepointcr  to  $TTI 

.SYSTM 
.OPEN  22 

JMP  ERROR 

;Opcn 

$TTI  on  channel  22 

JMP  RT 

;  Jump 

to  return  location  when 

compiece 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERROR:  .SYSTH 

•EUTN  ; Abnormal  return  -  error 

JMP  ERROR 

:  BYTEPOINTERS  DEFINED 


NTTO: 

.  +  1*2 

.TXT  "$TTO" 

;Bytcpointer 

to  device 

$TTO 

NTTI: 

.  +  1*2 

.TXT  "$TT1" 

;Bytepointcr 

to  device 

$TTI 

RT:  JSR  @  .FRET 

FS,=0 

TMP=-167 

•END  BGIN 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+ 

+  END  BGIN. SR 

+ 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ++  +  +  +  +  + 


+ 


t 


+ 

+ 

+ 

+ 

+ 


i 


124 


+  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+ 

+  PROMPT. SR 

+  CREATED  3  JULY  1980;  REV  01  **** 

+ 

+  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+ 

+ 

+ 

+ 

+ 

+ 


ic'k'k-k'k'k-k'i.-k'k 

Program  PROMPT. SP,  is  called  from  MONITOR. FR  and  returns  to 
MONITOR.  It  is  called  several  times  within  MONITOR,  each  time 
to  provide  the  user  a  prompt  that  inforpiation  may  be  entered. 

The  prompt  character  for  MONITOR  is  ">"  .  There  are  no  arguments 
or  parameters  that  are  passed  via  PROMPT. 

'k'k'k'k'k'k'k'k'k'k 


.TITL  PROMPT 
.ENT  PROMPT 

.TXTM  1 
.EXTU 

.EXTN  .1 


;Program  name  -  Prompt 

;Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

;Provides  some  FORTR/iN  initialization 


.NREL  ;Normal  relocatable  space  starts 

FS, 
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v.’RiTE  pko::pt  to  $tto 


PROMPT; 

JSR  @  .EARL 

START: 

SUB  1,  1 

jl.oaci  default  mask 

LDA  0,  PRMT 
.SYSTM 

;Load  bytepointer  to  prompt 

.WRL  21 

JMP  ERROR 

;Write  pro:’.ipt  to  channel  21 

JMP  RT 

;Jurip  to  return  location  wlien  complete 

ROUTINE  TO  RETURN  TO  THE  CM  ABNORMALLY 


ERROR:  .SYPTM 

.ERTN 
JMP  K!;Rf  H 

;  BYTLPOINTj  i:  iUT'IM') 


pRrrr: 


.  +  1--2 
.TXT 


jAbnornal  rcLurn  -  error 


;Bytcpo inter  to  pror.iPt  -  >  (with 
;carriage  return) 


RT;  JSR  (J  .FRET 


KS.=0 

TMP=-1C7 


•END  IROMPT 


+  +  •^  +  +  ^  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  PROMPT. SR  + 

+  + 

+  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


i 
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+  +  +  +  +  +  +  +  +  +  +  +  +  4  4  +  +  +  •♦+  +  +  +  +  +  +  + 


+  + 

+  REVERT. SR  + 

+  VrVr*-;:  CREATED  13  JULY  1980;  REV  01  + 

+  + 


+  +  +  +  +  4  +  +  +  +  +  +  +  -f4  +  +  +  +  +  +  +  +  +  +  +  + 


'k'k'k'k'ic'i.  .'  k-k'k 

Progi'ain  RLVr.RT.SI!  is  called  fron  HOI.'ITOR .  F'R  and  always  returns 
to  Lie  ’Mccal"  CLI.  This  program;  is  called  by  the  user  entering 
"''L"  anywhere  in  the  line  that  follov;s  a  prompt.  There  are  no 
parameters  or  argur;;ents  that  arc  passed  via  REVERT. 

*  *  'k  k  k  k  k  k  k 


.TITI.  REVERT 
.ENT  REVERT 

.TXTM  1 
.  EXTU 

.EXTN  .1 


; Program  name  -  Revert  to  CLI 

;Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

;Provides  some  FORTRAN  initialization 


.NREL  ;Normal  relocatable  space  starts 

FS. 
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NOTIFY  USLK  OF  R1:TU1IN  TO  CLI 


REVF.RT:  JSK  G  .FAUN 

SUB  1,  1 
LDA  0,  NOTi'A 
.SYSTM 
•WKL  21 
JMP  ERROR 

;  ROUTINE.  FOR  NOR’iAL  RETURN  TO  TNF,  CLI 


START;  .SYSTM 

.RTI!  ;Nornial  return  -  no  error 

JMP  i:rror 

JUP  KT  ;Juirip  to  return  location  \;hf;n  cruaplc 

;  ROUTINE  TO  RETURN  TO  TEE  CLI  ABNORMALLY 


ERROR:  .SYSTM 

•ERTN  ;Abnonnal  return  -  error 

JMP  ERROR 

;  RYTEPOINTER  DEFINED 


NOTEA:  .+1*2  ;Bytepointcr  to  message  (NOTEA) 

.TXT  "You  have  returned  to  the  local  CLI  inocie.<15>" 


RT:  JSR  G  .FRET 

FS.=0 

TMP=-167 


;Load  default  masl< 

;Load  bytepointer  to  mos.sagn 

iWrite  message  to  channel  21  ($TTO) 


END  REVERT 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


+ 

+■ 

+ 

+ 


+ 

getrsps.fr  + 

****  CREATED  8  AUGUST  1980;  REV  00  ****  + 

+ 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


Program  GETRSPS.FR  is  called  by  MONITOR. FR  and  returns  to 
MONITOR.  Its  sole  function  is  to  read  the  selected  action  file 
(seeking  that  line  that  begins  with  the  control  character  "I"  in 
column  one  (1))  and  store  up  to  two  (2)  possible  responses  that 
are  expected  from  the  "system"  when  intercommunication  is  taking 
place . 

The  call  to  GETRSPS  is  as  follows; 

CALL  GETRSPS  (INTRY, IRSPl , IRSP2 , IlSSZ , I2SSZ) 

(Integer)  INTRY  is  the  user  inputed  channel  number  of  the 
selected  action  file  and  is  the  only  parameter  passed  from 
MOh'ITOR  to  GETRSPS.  The  remaining  parameters  are  returned  from 
GETRSPS  to  MONITOR.  They  are: 

IRSPl  -  one-dimensional  array  containing  first  response, 
if  any 

IRSP2  -  same  for  second  response,  if  any 
IlSSZ  -  integer  that  indicates  size  of  IRSPl 
I2SSZ  -  same  for  IRSP2 

•k'k'k'k'U’ff'feie'k'it 
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noon 


c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 


I'ARAMIORTKR  MDIMl  is  tlip  r.izo  of  the  one-el  i  mens  i  ona  1  comnainJ 
sequciu’.e  array.  MDJM3  is  the  size  of  the  ono-diinensional 
response  arrays. 

PAlWaiETER  IIDIMI  =  82.  MDIH3  =  40 

GETRSPS  receives  an  input  channel  and  returns  the  first  and  *" 
second  responses  (if  any),  as  well  as  their  sizes. 

SUHROUTINE  GETRSPS  ( IKCHAN ,  1 1 STRSP ,  I2NDRSP ,  1 1 STSZ ,  I2h’DSZ ) 

IIMITAR  is  an  initialized  array  that  stores  the  coii\::’.and  ** 

sequence  line  as  read  from  the  action  file.  It  parallels  the 
use  of  lACTFILE  in  MOh'lTOR. 

DIMENSION  llMITARdlDIMl),  llSTRSP(:iDXM3 ) ,  I2NDR5P(HDIM3 ) 

**  Characters  used  for  comparisons  and  decisions  are  data-  ** 

initialized.  They  must  therefore  be  declared  COMMON. 

COMMON  /IKONST/  KLTRI,  KSPACE,  KOMMA 

DATA  KLTRI, KSPACE. KOMMA/  "<111><40>" , "<40><40>" , "<54><40>"/ 

Since  the  response  arrays  may  be  empty,  they  mnst  be  ** 

cleared.  Then,  if  no  responses  are  provided,  the  expected 
response  will  bo  blanks  or  spaces  by  default. 


DO  1002  JJ  =  1,  HDIM3 

IISTRSP(JJ)  =  KSPACE 
I2NDRSP(JJ)  =  KSPACE 

1002  CONTINUE 
C 

C  *■*  Read  a  line  out  of  the  action  file  and  begin  search. 
C 

1004  READ  (IKCHAN.IOOG)  (IINITAR(II),  II  =  1,  MDIMl) 

1006  FORMAT  (82A1) 

C 
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C  ■**  If  the  control  clinracter  "I"  is  not  cncountcrec! ,  read  the  ** 
C  next  line  of  the  action  file  until  such  a  lino  is  encountered. 

C  (NOTK:  Each  action  file  must  have  a  line  with  control 

C  character  "1"  or  GETR.SPS  will  generate  an  error  condition.) 

C  When  the  desired  line  is  encounter* d,  begin  searching  for  a 

C  response  in  column  nine  (9)  and  beyond.  If  nothing  is  there, 

C  return  to  the  calling  program.  If  a  separator  cormna  is 

C  encountered,  there  are  two  responses.  Cet  the  first  and  then 

C  get  the  second.  Otln.-rwise,  get  the  first  response  only  and 

C  return  to  the  calling  program. 

C 

IF  (IINITAR(I)  .NE.  KLTKI)  GO  TO  1004 
DO  1008  ISUBl  =  9,  IIDIMI 

IF  (IINITAR(ISUBI)  .EQ.  KSI’ACE)  GO  TO  1014 
IF  (llNITARdSUBl  )  .EQ.  KOlBiA)  GO  TO  1010 
IlSTRSPdSlIBl  -  8)  =  IIKllARdSUBl) 

IlSTSZ  =  ISUBl  -  8 

1008  CONTINUE 
C 

C  **  Begjin  the  search  for  the  second  response,  if  any.  Return  ** 
C  to  the  calling  program  v/hen  completed. 

C 

1010  IPISUBI  =  ISUBl  +  1 

DO  1012  ISUB2  =  IPISUBI,  MDIMl 

IF  dlNITARdSUB2)  .EQ.  KSPACE  .OR.  IINITARdSUB2) 

+  .EQ.  KOMMA)  GO  TO  1014 

I2NDRSPdSUB2  -  ISUBl)  =  IINITARdSUB2) 

I2NDSZ  =  1SUB2  -  ISUBl 

1012  CONTINUE 
C 

c 

C  **  Before  returning  to  the  calling  program,  the  pointer  to  the 
C  action  file  must  be  reset  to  the  beginning  of  the  file.  FSEEK 

C  resets  the  pointer  to  the  beginning. 

C 

1014  CALL  FSEEK  dNCllAN,0) 

C 

RETURN 

END 

C 

C - 

g - 

c 

c  +++++++++++++++++++++++++++ 
c  +  + 

C  +  END  GETRSPS.fr  + 

C  +  ■  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ++  +  +  +  +  +  +  +  +  +  +  + 

C 

C - 

C - 
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+  +  +  +  +  +  +  +  +  +  •♦  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+  CNVRT.SR 

+  CKKATED  13  JULY  1980; 

+ 

+  +  +  4+  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+ 

+ 

RKV  04  ****  + 

+ 

+  +  ^+  +  +  +  + 


•kic-k  kkic  k  k  k  k 

PrOt;rain  CNVKT.SR  ir.  called  from  HCiNITOK.KK  and  returna  to 
MONITOR.  It  is  called  after  GKTKSRS.FR  and  serves  to  convert 
the  FORTRAN  array  storage  to  assembly  lan;;uage  storage.  Foe  example, 
the  character  "A"  is  stored  in  FORTIt/vI:  array  IKSPl  as  <101><4C>, 
whereas  the  same  character  is  stored  in  assembly  langgioge  as 
<0><101>.  Thus,  this  program  simply  converts  bettoren  tin.-  two. 

The  call  to  CNVRT  is  as  follows: 

CALL  CNVRT  (IRSPl , 1RSP2 , II SSZ , I2SSZ) 

IRSPi  and  IRSP2  are  one-dimensional  FORTRAb’  arrays  that  arc  passed 
from  MONITOR  to  CNVRT.  They  contain  the  rerponses  as  found  by 
the  program  GETRSPS.  IlSSZ  and  I2SSZ  arc  tin  size  of  the  response 
arrays,  and  are  parameters  that  are  passed  froiii  CNVRT  to  MONITOR. 

Upon  completion  of  CNVRT,  the  assembly  languagt>  responses  and  their 
sizes  are  stored  in  BUFl ,  BUF2,  .FBI,  and  .FB2,  respectively. 
Subseciuent  programs  then  use  these  locations  for  comparison 
purposes,  when  checking  for  appropriate  responses. 

kkkkkkkkkk 


.TITL  CNVRT  jProgram  name  -  Convert 

•ENT  CNVRT  ;Enables  outside  entry  into 

.ENT  .BUFl,  .BUF2,  .FBI,  .FB2  ;this  program  and  these  locations 

.TXTM  1  ;Packs  ASCII  strings  left  to  riglit 

.EXTD  .FSUB,  .FREDI  ;FORTRAN  runtime  library  routines  must 

;be  decleared  external  dispiacements 

.EXTU  ;Undefined  variables  are  treated  as 

;External  Displacement  variables 

.EXTN  .1  ;Provides  some  F0RTRj\N  initialization 
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f 

.ZREL 

;Zero 

relo 

eatable  space  starts 

.FBI  ; 

0 

;  Store 

for 

the  size  of  first  re: 

sponsG 

.FB2: 

0 

;SaDie 

for 

second  response 

.BHFl  : 

BUFl 

; Buf  f  e 

rc  t 

liat  contain  responses 

may  be 

.BUF2: 

BUF2 

;addrc 

ssed 

indirectly  via  these 

location 

.NR  EL 


jNonr^al  relocaLoble  space  starts 


FS. 


ESTABLISH  THE  ARRAYS  PASSED  l.N  AS  DUItllY  ARGUl'ENTS 


CNVRT;  JSR  0  .FARL 


JSR  Q  .FRED 
ARy21N 
(3  STORA+1 
STOPa'i+4 


;Rediinension  an  array,  passed  as  dumny 
jargument.  This  is  array  specifier 
;This  is  array  size  -  dnimr./  argument 
;This  is  three  word  stae’'  cfctifitr 


JSR  @  .FRED 

ARYIIN  ;Sonie  for  the  other  array 

0  STORA+0 

STORA+7 


STORE  SIZE  OF  RESPONSES 


LDA 

1  , 

PTMP+3,  3 

;Loco  size  of  second  array 

from 

STA 

1. 

.FB2 

;FORTRAN  stack  -  store  in 

.FB2 

LDA 

1, 

C''TMP+2,  3 

;Satue  for  first  array,  but 

STA 

1. 

.FBI 

jstore  in  .FBI 
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SELECT  EACH  ELEMENT  OF  T1!E  FIRST  ARRAY 


» 

LDA  0,  MINI 2 SUB 

;Load  subscript  one 

STA  0,  TMP+12, 

3 

;Store  on  stack 

JMP  STRTl 

;Start  iterations 

INCIS: 

LDA  0,  TMP+12, 

3 

;On  repeated  passes,  get  the 

INC  0,  0 

;last  subscript  and  increment  it 

STA  0,  TMP+12, 

3 

;Store  new  subscript 

STRTl : 

LDA  1,  @TMP+2, 

3 

;Load  maximum  subscript 

SUEZ  0,  1,  SNC 

;If  maximum  exceeded. 

JMP  NXTRSP 

;start  same  type  iteration  on  next  array 

JSR  @  .FSUB 

^Otherwise,  get  the  array  element 

3 

;Number  of  arguments  for  library  call 

STORA+7 

;St3ck  specifier  for  first  array 

STORP+1 

;Temporary  location  for  FSUB  result 

STORA+12 

;FORTRAN  address  of  subscript 

;  CONVERT  FROM  FORTRAN  TO  ASSEMBLY  LANGUAGE  STORAGE 

>  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — 


LDA  0,  @TMPP+1,  3 

LDA  2,  MSKSAP 

ANDS  2,  0 

STA  0,  @DUF1PTR 

LDA  1,  BUFIPTR 

INC  1,  1 

STA  1,  BUFIPTR 


;Load  selected  array  element 

;Delete  second  byte,  strip  parity  from 

jfirst  byte,  and  swap  bytes 

jStore  result  in  BUFl 

;Load  pointer  to  BUFFI 

; Increment  and  store  the  new 

;pointer 


JMP  INCIS 


;Continue  the  next  iteration 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNOPvMALLY 


ERROR:  .SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  ERROR 
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DEFINE  INITIAL  SUBSCRIPT  SIZE  FOR  BOTH  ARRAYS 


MIN12SUB:1 

:  REPEAT  THE  ABOVE  PROCEDURE  FOR  THE  SECOND  ARRAY 


NXTRSP:  EDA  0,  NIK12SUB 
STA  0,  TMP+12,  3 
JMP  STRT2 

INC2S;  LDA  0,  TMP+12,  3 
INC  0,  0 

STA  0,  TMP+12,  3 

STRT2:  LDA  1,  @THP+3 ,  3 
SUBZ  0,  1,  SNC 

JMP  RETN  ;Return  to  calling  program 

JSR  @  .FSUB 
3 

STORA+4 

STORP+2 

STORA+12 

LDA  0,  0TMPP+2,  3 
LDA  2,  MSKSAP 
ANDS  2,  0 

STA  0,  @BUF2PTR  ;Store  result  in  BUF2 

LDA  1,  BUF2PTR 

INC  1,  1 

STA  1,  BUF2PTR 

JMP  INC2S 


i 

I 

I 


I 

I 
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I 


DKKl.M':  ri)lMr,!.S,  VARA!  Iil.!:s,  AM)  lilUM-.U;’. 


KSKSAP:  07 7 AGO 


BI'1’1PTR:E0F1 

BUF2}’TK;BU1''7 


;Matik  for  Ft  r  i  pi'iii;’,  parity,  ciil(tin.; 
; second  byte 

;l*oii!ter  to  BUF) 

;Point.er  to  Bl'F2 


BUFl:  .BLK  40.  jDefine  buffer  si^es 

BUF2:  .Bbi:  40. 


RETN:  JSR  G  .FRFT 

:  SPECIFY  TEE  AitRAYS 


ARY21N: 

3 

;Thi  F 

is 

-  2*(nur;iber  of  siibsri  iptsl  +  l 

401 

;  Th  i  s 

is 

-  400"  1  +  1,  leti,  tb’-j  and  type 

Kri;l  2SUB 

-.This 

i  s 

lo\.’er  subscript  sire 

0STORA-t3 

;  Th  i  s 

is 

hiphcr  subscrip’t  sir, C’ 

ARYllN: 

3 

;Thi  s 

i  s 

the  sar.o  for  first  array 

401 

MIN12S0B 

0STURA+2 

DEFINE  STACK  PARAMFTFFS 


FS.=17 
TMr=-167 
STOPJi=200  ii:P 
Th;PP=TMP+12 

ST0RP=--ST0RA+12 


iFranc  size  for  all  stock  vnriaiilfs 
jMiddle  of  the  user's  slack 

;First  word  available  for  lenporary 
; storage 


.END  CNVRT 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  •♦  +  +  +  +  ^+  ■♦  +  + 
+  + 

+  END  CNVRT. SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ♦  +  +  +  +  +  +  ♦  +  + 
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c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c- 

c- 

c 


+  +  +  +  +  +  +  +  +  +  H  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 
+  WRIT  SYSTK.fr  + 
+  ****  CREATKD  8  AUGUST  1980;  RFV  00  ****+ 
+  + 
+  +  +  +  -t  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


"icfc  "icii 'iff  "if  "ic 'Jc 


c 

C  Prof,r.-.in  WKITSYSTM.FR  is  cnlled  by  MONITOR. ]'R  and  returns  to 

C  MONITOR,  whenever  a  command  sequence  froni  .in  action  file  is 

C  ready  to  be  sent  to  tlu*  "system."  WRITSYSTM  provides  a 

C  transition  to  and  from  an  assenibJy  language  subroutine  that 

C  actually  transmits  data  to  the  "system."  The  call  to 

C  WRITSYSTM  is  as  follows. 

C 

c  CALL  WRITSYSTM  (lACTFILE.NRTMSTINDX , $602) 

C 

C  lACTFILE  is  one  line  from  the  action  file  that  is  to  be  sent 

C  to  the  "syfiten."  NRTMSTINPX  is  the  size  of  t!ie  one-dimensional 

C  array  lACTFll.L,  and  $602  is  the  return  line  number  in  MONITOR 

C  that  will  next  be  executed  upon  return  from  WRITSYSTM.  All 

C  paraPiOters  arc  passed  to  WRITSTSTM  from  MONITOR. 

C 

C  'kick'k'k'f.'k'k'k'k 

c 

C - 
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■"*  Vi; ] '1  rc'Coi v.'s  an  input  array,  the  d i ji-cns ion  of  that  ** 

array,  and  an  ap.s),;m(I  diuMny  rLlurn  variable. 

sunihU'Ti ;;r,  '..’r i TSYsm  ( i i:i array , 1 1 uuwR, i idujirth) 

D  T  i:h!;s  1  ON  1 !.  1  ARRAY  ( 1 1  Di;  a\R  ) 

WP.SYS  actually  transuits  the  contents  of  INIARRAY  (of  size  ** 
liMRIJlAR)  to  the  "systcni." 

CALI,  \,'RSYS  (IKIARRAY,  IlDIlfAR) 

**  Return  to  the  statement  number  passed  in  IIDUMRTN  ** 

RETURN  IIDU.’IRTN 
END 


+  +  +  +  +  +  +  +  +  +  ^•  +  +  +  +  +  +  +  +  +  +  +  +  +  +  *f  + 


END  WRITSYSTll.FR 


+  +  +  +  +  +  +  +  +  +  +  t+  +  +  +  +  +  +  +  +  +  +  +  t  +  + 
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+  +  -I-  +  +  +  +  +  +  +  -^+  +  +  +  +  +  +  +  +  +  ^+  +  +  +  + 


+  + 

+  VmSYS.SR  + 

+  ****  CRnATED  15  JULY  1980;  REV  OJ  + 

+  + 


+  +  +  -»+  +  +  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  +  + 


Program  \/RSYS.SR  is  called  from  I/RITSYST”. FR  and  returns  to 
WRITSYSTl!.  Its  solo  function  is  to  transmit  data  to  tlie  "system. 
The  data  is  alv.ays  a  cor.m-.and  of  the  action  file.  The  call  to 
WRSYS  is  as  follows: 

CALI,  UKSYS  (IKIARRAY,  IlDIMAR) 

IK1ARPJ\Y  is  one  line  from  the  action  file  that  is  to  be  sent  to 
the  "systcr.i."  IlDIl'AR  is  the  size  of  the  ono-diirxntional  array 
INlARKAY.  Both  these  parameters  are  passed  from  l.’RITSYSTM  to 
VRSYS. 


-k'k'Jcic'k'k'k'k'k'k 


,TITL 

WRSYS 

;Program  name  -  Write  to  System 

.ENT  WRSYS 

;Enables  outside  entry  into  this 
; program 

.  TXTM 

1 

;Packs  ASCII  strings  lift  to  right 

.EXTD 

.KSUB,  .FREDI,  .LDl 

;FORTRAN  runtime  library  routines  must 
;be  declared  external  displacements 

.EXTU 

;Undefined  variables  are  treated  as 
;External  Displacement  variables 

.  EXTM 

.1,  .ASUSP 

;.I  provides  some  FORTRAN  initialization 
; .ASUSP  is  a  task  call  for  suspension 
;and  must  be  declared  external  normal 

.NREL  ;Normal  relocatable  space  starts 

FS. 
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SKPBZ  TTOl 
JMP  .-1 
DOAS  0,  TTOl 
JMP  INCSUB 

DEFINE  VARIABLES 


CR:  15 

LOWSUB:  11 

MSKIT;  077A00 

TSKPRI:  0 
MINSUB:  J 


;lf  the  output  line  (channel  device  $T'T'0 
;is  busy,  try  again 
;Otherwise,  output  the  character 
;Continue  the  next  iteration 


;Carriage  return  is  octal  15 
;9  decimal  -  subscript  that  starts 
;action  file  text 

;Mask  for  stripping  parity,  deleting 
;second  byte 

;MONITOR's  task  priority 

;The  lower  subscript  starts  at  one 


lAO 


SPl'CirY  TtlK  ARRAY 


:  3 

;  Thi  s 

is  -  2‘'''(number  of  subscript 

r. )  +  1 

AOl 

;  Til  i  s 

is  -  400"1  +  1,  longtii”!  and 

type 

hilNSUB 

;  Til  is 

is  lower  subscript  size 

0STorw‘.+] 

;This 

is  higher  subscript  size 

O'JTPUT  CARKIAGE 

LFTl'RK,  SUSPEND  MONITOR, 

AND  RETURN 

RET;  LDA  0,  CR 
SKFBZ  TIOl 
JMP  .-1 
DOAS  0,  TTOl 

LDA  0,  TEKPRI 
.ASUSP 


;liOad  carriaf.o  return 
;Outpiit  it  v;hen  $XT01  not  busy 


;l.oad  MONITOR  task  priority 
;Suspcnd  IIOlilTOU  -  task  SYSIN  will 
; ready  MONITOR 


JSR  0  .FRET 

DEFINE  STACK  PAPvAMETERS 


FS.  =  7 
TMP=-167 
STOPY.^  200+TMP 
TnPP=TMP+5 


STORP-STORA+5 
•END  WRSYS 


;Frame  sir.e  for  all  stack  variables 
;Middlc  of  the  user's  stack 

;First  word  available  for  temporary 
; storage 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  WRSYS. SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


lAl 


c - - - - — 

c 

C  +  ^  ^  +  +  +  +  -I  +  +  H  +  +  -:++  +  ^  +  +  +  +  +  +  +  ■!  + 


C  +  + 

C  +  V,’U1TL(K:AI..KR  + 

c  +  CRKATEIJ  8  AUGUST  1  980;  RKV  00 

C  +  + 


C  +  +  +  +  +  +  +  I-  +  +  +  +  +  +  +  +  +  +  ^-  +  +  ^  +  ^^  -^•  + 

c 


c 

c 

C  Program  l.'RITLOCAL.  FK  is  called  by  I-OUITOR.  FR  .-nKl  returns  to 

C  liOMITOR,  wlirncvcr  n  corirnrnd  s.qucnce  frori  an  action  file  is 

C  ready  to  be  sent  to  the  "local"  teri’ninal.  V.’Kl'J  LtiCAL  sir-.pl  y 

C  writes  a  sti-iiif,  contained  in  army  1K2A!.RAY  to  the  "local" 

C  tentinal.  The  call  to  lo'UTLOCA).  is  as  follows: 

C 

C  CALL  V'RITLOCAL  (  lACTFlL.F.MDi;!!  ,  $602) 

C 

C  lACTFILE  is  one  line  froi.i  the  action  file  that  is  to  be  sent 

C  to  the  "local"  terminal.  IIDILI  is  the  sire  of  the  one-d iment iona 1 

C  array  lACTFILE,  and  $602  is  LiiC'  ’"i  torn  lino  nn:,.her  in  MOillTOK 

C  that  will  bo  next  executed  upon  return  from  l.'RITLOCAL.  All 

C  paramoters  arc  passed  froni  LCL'l'lCiR  to  L'i;i'iL()CAL. 

C 

C  'k'k'ic'ii'k'X  k-kk-t: 

c 

C - 

C - 
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o  o 


C  VJRITI.OCAL  receives  an  input  array,  the  dimension  of  that 

C  array, and  an  assigned  dummy  return  variable. 

C 

SUBROUTIh’h  I.’RITLOCAL  (  I  K2ARnAY ,  I2DIMAR ,  I2DUtiKTK) 

D I MEK S 1 ON  I K 2 AURA Y ( 1 2 D niAR ) 

C 

C  ■"*  The  contents  of  the  action  file  line  arc  written  to  ch.anne 
C  10,  the  "local"  terminal  device  ($TT0). 

C 

WRITE  (10,  2001)  (IN2ARRAY(J1),  Jl  =  3,  I2DIM\R) 

2001  FORMAT  (80A1) 

C 

C  **  Return  to  the  statement  nu'nber  passed  in  I2DUMRTN. 

C 

RETURN  I2DUMRTN 
END 
C 

C - 

C - 

c 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  -!•  +  +  +  +  +  +  + 

c  +  + 

C  +  END  URITLOCAL.fr  + 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  H  -I  H  +  + 


1A3 


ooooonoooooo  noo  non  onnooooononoonn 


+  +  +  +  +  +  +  +  +  +  +  +  +  ■!  +  +  +  +  ■»  +  +  +  +  +  ^  +  + 


C 

c- 

c 

c 

c 

c 

c 

c 

c 

c 

c- 

c- 

c 

c 

c 

c 

c 

c 

c 

c 

c 


+ 

+  readlwrits.fr 

+  ****  CREATED  8  AUGUST  1980;  REV  00 

+ 


+ 

+ 

■k'k-k  X  + 

+ 


+  4+  H  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


■ic'k'X'X'X  XX'XX'X 

Program  READL\JR1TS . FR  is  called  by  HOUITOR.FR  and  returns  to 
MONITOR,  wlKiicvcr  a  command  sequence  from  an  action  file 
indicates  that  something  is  to  be  read  from  the  "local"  terminal 
and  a  c.arraiagc  return  is  to  be  sent  to  the  "system." 

READLUKITS  provides  a  transition  to  and  from  an  assembly 
language  subroutine  that  actually  reads  data  from  the  "local" 
terminal  and  writes  a  carriage  return  to  the  "system." 

The  call  to  READLWRITS  is  as  follows: 


CALL  READLWRITS  (8602) 


The  $602  is  the  return  line  number  in  MONITOR  that  will  next 
be  executed  upon  return  from  READLWRITS. 

•k  k  k  k  k  k  kkk 


**  READLWRITS  receives  an  assigned  duirany  return  variable. 

SUBROUTINE  READLWRITS  (l3DUflRTN) 

**  RDAWR  actually  implements  the  read  and  write  functions. 
CALL  RDAWR 

**  Return  to  the  statement  number  passed  in  I3DUMRTN. 

RETURN  I3DUMRTN 
END 


4-  +  4-4-4-4-4-4-4-  +  4-4-4-4-  +  4-4-4-4-4-4-4-4-4-  +  4-4- 
4-  4- 


4- 


END  READLWRITS.fr 


4- 


4- 


4- 


4-4-4-  +  4-4-4-  +  4-4-4-  +  +  4-  +  4-  +  +  4-4-4-4-  +  4-4-4  4 


144 


RDAWR . SR 

'k'k'k'k 


+  +  +  +  +  ^  +  +  +  +  +  +  +  +  +  +  +  +  +  ^ 

+ 
+ 

CREATED  3  JULY  1980;  REV  03  ****  + 

+  + 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  •*+  + 


’k'k'Jc'krk'k-^ii'k-k 

Program  RDAV/R.SR  is  called  from  READLV7RITS .  FR  and  returns  to 
READLWRITS.  Its  sole  purpose  is  to  await  any  keyboard  input 
and  then  transmit  a  carriage  return  to  the  "system."  This 
routine  is  only  called  during  LOGON  processing.  There  are  no 
arguments  or  parameters  that  are  passea  via  RDAV/R. 


i. 


II  fine 


Read  And  Write- 


.Tin.  RlJAi.’H 


;  Pro[' ran 


.ENT  RDAt.’K 


;F.nab]c'S  outside  entry  into  this 
; program 


.TXTM  1 
.  EXTU 

.EXTN  .1,  .ASUSP 


;Packs  ASCII  strings  left  to  right 

;Undcfined  variables  are  treated 
;as  External  Displacement  variables 

;.I  provides  some  FORTRAN  initialization 
;. ASUSP  is  a  task  call  for  suspension 
;and  must  be  declared  external  normal 


.ZREL 


;Zero  relocatable  space  starts 


.ER:  ERROR 


;Acccf;s  to  ERROR  may  be  gained  via 
;indirect  addressing  to  this  location 


.NREL  ;Konnal  relocatable  space  starts 

FS. 

WAIT  FOR  KEYBOARD  INPUT 


RDAWR: 

JSR  0  .FARE 

RERD: 

. SYSTH 

.GCHAR 

;Get  input  character  from  keyboard 

JMP  (3  .ER 

SKKD  CAKKlAl.i:  RKTUHN  TO  5TTO] 


l.DA  0.  OK 

;Load  n  carringe  return 

.SYSTM 

.PCllAl; 

;Ouli>ut  carria^’.e  return  to  $TT 'J 

JMP  0  .F.R 

SKPEZ  TTO) 

;Is  $TT01  busy? 

JMP  .-1 

;Yes  -  try  np.ain 

POAS  0,  TTUl 

;No  -  output  enrriai;e  return  to  $TTOl 

> 

> 

SUSPEtM)  TIM  TASR  MOMTOl: 

TO  ALEO'..'  SYS  IN  TO  EXECUTE 

EDA  0,  TSKPRl 

;Eoad  MONITOR'S  task  priority  iO) 

.ASUSP 

;Suspend  flONlTOP.  ui,til  readii-d  in 

;tabl<.  SYSIN 

JMP  RTN 

•.Jump  to  return  location  vMien  cuaplete 

1 

DEFINE  VARIAP.LFS 

TSKPRl  :  0 

;KONITOR'.s  task  priority  is  rero 

CR: 

15 

;A  carriage  return  is  octal  15 

) 

KOL'TINE  TO  RETURN  TO  THE 

CEI  ABNCRMAELY 

KRIIOR:  .SYSTM 

.ERTK  ;Abnoriiial  return  -  error 

JMP  Q  .ER 


> 

RTN:  JSR  0  .FRET 


FS.=0 

TMP=-167 

.END  UDAWR 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  RDAWR.SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  4  +  +  +  +  + 
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ooooooooo 


c 


c— 

— 

.  — — - 

c 

c 

+  -1 

+  +  +  +  + 

+  +  +  -(-  + 

+ 

+  +  +  + 

+  +  + 

+  + 

+  + 

+  +  + 

c 

+ 

+ 

c 

+ 

SENDFILE, 

.Fi; 

+ 

c 

+ 

CREATED 

8 

AUGUST 

1980; 

REV 

00 

c 

-f 

+ 

c 

+  + 

+  +  +  +  + 

+  T  +  +  + 

+ 

+  +  +  + 

+  +  + 

+  + 

+  + 

+  +  + 

c 

c~ 

c - 

c 

'k'kic'k'k’ic'k'k'k'k 

c 

C  Program  SKNDFILE.PK  is  calloci  by  MONITOR . I-’R  snd  returns  to 

C  MONITOR,  whenever  a  conmand  sequence  from  an  action  file 

C  requires  a  "local"  disk  file  to  be  sent  to  the  "syster." 

C  SENDFILE  uses  the  RDOS  file  CLI.CM  to  "send"  action  file  cormiands 

C  r.o  the  "local"  system.  Thus,  the  action  file  coiramnand  is  inserted 

C  into  CLI.CM  and  tlx.n  a  program  swap  takes  place  to  execute  that 

C  coutiTiand.  When  swapping  takes  place,  functions  v;ithin  tasks  are 

disabled  (such  as  .IDLl').  Therefore,  the  task  SYSIN  is  inactivated 
(killed)  and  reactivated  before  and  after  the  swap  -  program 
EXCLI.SR.  Finally,  program  GETFILE.SR  actually  transmits  the 
data  retrieved  from  the  "local"  disk  and  sends  it  to  the 
"system."  The  call  to  SEMDFILE  is  as  follows: 

CALL  SEIIDFILE  ( IACTFILE,MDIM1  ,  $602 ) 

lACTFILE  is  one  line  from  the  action  file  that  is  to  be 
C  acted  upon  by  the  "local"  system.  MDIMl  is  the  size  of  the 

C  one-dimensional  array  lACTFILE,  and  $602  is  the  return  line 

C  number  in  MONITOR  that  will  next  be  executed  upon  return  from 

C  SENDFILE.  All  parameters  are  passed  to  SENDFILE  from  MONITOR. 

C 

C  ic'kic'k'k'k'k'k’k'k 

c 

c - 

C - 


I 
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O  Ci 


c 

C  "■''  SEIJDl'ILE  roccivos  an  input  array,  Lhn  diir.onsion  of  that  ** 

C  army,  and  an  assigned  dummy  return  variable. 

C 

SUCROUTIt.'E  SFHDFILK  ( IRViARRAY  ,  I4I)IMAR  ,  I4DU!IRTN ) 

C  **  SYSIN.SR  is  the  task  program  that  monitors  "system"  input  ** 

C  and  was  activated  by  MONITOli.  As  it  is  to  be  killed  and  then 

C  reactivated,  DG  FORTRAN  reejuired  that  it  be  externally  defined. 

C 

EXTERNAL  SYS IN 

DI  MENS  I  ON  I K4ARRAY  (  I4DIMR  ) 

C 

C  **  This  call  creates  file  CLI.CM.  If  it  already  exists,  an  ** 

C  error  of  12  is  returned  in  ICERRl .  If  the  call  is  okay,  an 

C  error  of  1  is  returned.  Any  other  error  is  printed  out  for 

C  reference.  This  insures  that  CLI.CM  is  available. 

C 

CALL  CFILW  ("CLI.CM", 2, KERRI) 

IF  (KERRI  .ME.  1  .ANi).  KERRI  .NE.  12)  TYPE  "KERRI  IS  ", KERRI 
C 

C  **  This  call  opens  file  CLI.CM  on  channel  25.  State  the  error  ** 

C  condition  if  not  opened  properly. 

C 

CALL  OPEN  (25,"CLI.CM",2,KERR2,82) 

IF  (KERR2  .NE.  1)  TYPE  "KERR2  IS  ",  KERR2 
C 

C  **  Insert  command  sequence  from  action  file  into  CLI.CM.  ** 

C 

WRITE  (25,4001)  (IN4ARRAY(K1),  K1  =  3,  I4DIM/iR) 

4001  FORMT  (in  ,  80A1) 

**  Close  CLI.CM  so  it  can  be  deleted  in  EXCLl.SR,  after  it  is  ** 

C  no  longer  needed. 

C 

CALL  CLOSE  (25,KERR3) 

IF  (KERR3  .NE.  1)  TYPE  "KERR3  IS  ",  KERR3 
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nan 


c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 


c 

c 

c 

c 


c 

c 

c 

c 

c 


**  Before  executing;  the  swap  (hXCLl),  inactivate  SYSili.  *»- 

SYSIN  is  the  only  task  with  priority  one  (1). 

CALL  AKILL  (1) 

*■"  EXCLI  swaps  to  level  two  (2)  to  execute  the  instruction 

just  inserted  into  CLI.CII.  Level  two  (2)  is  the  RDOS  CLI. 

Upon  conpletion  of  tlie  swapped  prograta,  control  returns  to  the 
next  instruction  in  this  program. 

CALL  EXCLI 

Reactivate  SYSIl!  just  as  it  was  before  the  sv;ap. 

CALL  ITASK  ( SYS  IN , 1 0 , 1 ,KERR4 , 1 ) 

IF  (KERR4  .KE.  1)  TYPE  "Kl’.RRA  IS  ",  KERR4 

**  GETFILE.SR  transr.iits  the  data  on  file  QQVV  to  the  "system."  "-t' 

CALL  GLTFILE 

**  Return  to  the  statement  number  passed  in  I4DUMRTN.  ** 

RETURN  14DUMRTN 
END 


+  +  +  +  +  +  +  + 

+ 

+ 

+ 

+  +  +  +  +  +  +  + 


+  +  +  +  +  +  +  +  +  +  ■(  +  +  +  H  +  +  +  + 

+ 

END  SENDFILE.fr  + 

+ 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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+  +  +  +  +  +  44  +  +  +  +  -I-  +  +  +  +  +  +  +  +  +  4  +H  +  + 


+ 

+ 

+ 

+ 

+ 


+ 


EXCLl .SR  + 

CREATED  11  JULY  1980;  REV  01  + 

+ 

+  +  +  +  +  +  4  +  +  +  +  4+  +  +  +  +  +  4  +  +  +  4  +  + 


^  vr  Vv  vr  irv  w  ^  w  V* 

Progmi:;  hXCLl.SK  is  tallod  from  SKMnKTLK .  KP.  and  RiXF.VF  IIP .  Fi; , 
and  i-rturus  to  SFPDFilF  and/or  RFCFVKl  I.F ,  uhitlievcr  proj’rarii 
called  PXFLI  Inst.  The  purpose  of  EXCI.l  is  to  execute  the 
RDOS  Cl, I  on  l(vel  tv;o  (2)  by  !;wappii\  the  CLI  in  and  sv/apping  out 
EXCLl.  A  command  from  the  action  file  has  been  inserted  into 
CLI. CM  by  (hither  SEh'hKlLE  or  RLCEVFILE;  this  swap  executes 
these  commands.  EXCI.l  also  appends  a  POP  command  in  the  CLI. CM 
file,  in  order  to  return  to  level  one  (1)  -  the  program  EXCLl  - 
upon  completion  of  the  corur.and  sequence  inserted  into  CLI. CM. 
There  are  no  arguments  or  parameters  that  are  passed  via  EXCLl. 

'k'k'k’k  'k  'k  k  k  k  k 


.TILL  EXCLl 
.ENT  EXCLl 


;PrograiT.  name  -  Execute  the  CLI 

jEnables  outside  entry  into  this 
;  program 


.TXTM  1 
.EXTU 

.EXTN  .1 


;Packs  ASCII  strings  left  to  right 

jUndefined  variables  are  treated  as 
;External  Displacement  variables 

;Provides  some  FORTRAN  initialization 


.NREL  jNormal  relocatable  space  starts 

FS. 
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ADI)  THE  POP  COMMAND  TO  FILE  CLI.CM 


EXCLI:  JSPx  G  .FARE 


SUB  1  ,  1 
LDA  0,  CL I CM 
.SYSTH 
.APPEND  23 
JMP  ER 

LDA  0,  CMAND 
LDA  1  ,  P'COUNT 

.SYSTM 
.V.’RS  23 
JMP  FR 
.SYSTM 
.CLOSE  23 
JMP  ER 


jLoacI  the  default  mask 

;Load  the  bytepointer  to  file  CLI.CM 

;Open  CLI.CM  for  appending  on  channel  23 

;Load  bytepointer  to  additional  coiimiand 
;Load  nutiber  of  bytes  to  be  written 

;Write  the  added  coirmtand  to  CLI.CM 

;Now  close  file  CLI.CM 


CALI,  S\.'AP  TO  EXECUTE  THE  CLl 


LDA  0,  CLISV 
SUB  1,  1 
SUBZL  2,  2 
.SYSTM 
.EXEC 
JMP  ER 
JMP  RT 


;Load  bytepcintcr  to  file  CLl.SV 
;Load  zero  -  indicatc;E  swap 
;Send  no  message  to  swap  program 

;Swap  to  CLI  on  level  two  (2) 

;Jutnp  to  return  location  when  complete 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ER:  .SYSTM 

.ERTN  ; Abnormal  return  -  error 

JMP  ER 


DEFINE  BYTEPOINTERS,  ETC. 


> 

CLISV: 

.  +  1*2 

.TXT  "CLl.SV" 

;Bytepointer 

to 

file  CLl.SV 

CL I CM: 

.  +  1*2 

.TXT  "CLI.CM" 

;Bytepointer 

to 

file  CLI.CM 

CMAND : 

.  +  1*2 

.TXT  ";P0P<15>" 

;Bytepointcr 

to 

POP  command 

BCOUHT: 

(BCOUNT-CMu\ND)*2 

jNumber  of  bytes 

in  POP  command 
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n;:;!.!;Tr  I'nj;  cli.cm  nin'ORK  Ki;Tuurnt;r  to  callii;g  pp.ociiam 

;l.oad  bylopointrr  Lo  file  CLI.CM 
;Deletc  file  CLI .CM 


JSR  P  .KUn’ 

FS  .=0 
TMP=-167 

•END  EXCLI 


LUA  0,  CLICM 
•SYSTM 
.DEEKT 
JMT  ER 


f  +  +  +  +  +  +  H  +  +  H  +  +  +  +  +  +  +  +  + 

^  END  EXCLI. SR 

^  +  +  +  +  +  +  +  +  +  +  +  4^  ^  +^  4  +  + 


•h  +  -f  -r  +  +  + 

+ 
+ 
+ 

+  +  +  +  +  +  H 
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<  +  +  +  +  +  +  +  +  +  +  +  +  +H  +f  +  +  -i  +  +  4  +  +  +  + 


+  + 

+  GETKTM:  .SR  + 

+  CRr.ATKD  26  JULY  1980;  Ri:V  02  + 

+  + 


+  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


^  "iSr  ^  VC  vr  vr  Vk  v«' Vv 

Prof^rrn’,  GKTFIUj.SR  is  called  froi.i  SENDFILE.FR  and  returns  to 
SEtlCFlLF.  It  is  called  after  EXCLI  l.as  placed  a  dif.k  file  of 
the  "local"  sysleia  into  file  ()QVV.  It  gets  this  file  and 
outputs  it  to  the  ".systct.i"  character  by  character.  It  call? 
upon  a  system  call  to  deteriviiiie  the  User  File  Discription 
status,  vdiich  provides  the  size  of  the  file.  There  are  no 
arguments  or  parameters  that  are  passed  via  GETi'ILE. 

V»  VC  V\  VC  VC  V'  VC  VC 


.TITL  GFTFILK 
•  F.NT  CKTFILE 

.TXTM  1 
.EXTU 

.EXTll  .1 


;Program  naire  -  Get  File 

;EnableG  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undofined  varaiblcs  are  treated  as 
•.External  Displacement  variables 

; Provides  some  FORTRAN  initialization 


.KREL  ;Normal  relocatable  space  starts 

FS. 
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oi’t:;;  and  K:t:D  P'jatus  of  filf  qqvv 


Gr.TFJl,L:JSR  (■'  .FA!;1. 

LI)A  0,  NAMOFFl. 

SUB  1,  1 
.SYSTi'l 
.OPEN  2G 
JMP  Eil 

L!)A  1.  ,  STREOC 
.SYSTM 
■  STAT 
JMP  EPv 

JMP  CALCSZ 

;  READ  QQVV  BY  FOKTJONS  ANN  SEND  OUT 


AGNKD:  I. DA  3,  SZOFFL 
LDA  1,  BYTSZ 
SUBZ#  1,3,  SNC 

JMP  LSTRD 

STA  1 ,  WRSSZ 
LDA  0,  PTRCMTS 
.SYSTM 
.RDS  26 
JMP  EU 

JSR  SFNDIT 

LDA  1 ,  DYTS2 
LDA  3,  SZOl-FL 
SUB  1  ,  3 
STA  3,  SZOFFL 
JMP  AGNRD 

LSTRD:  LDA  0,  PTRCNTS 
LDA  1 ,  SZOFFL 
STA  1,  VJRSS2 
.SYSTM 
.RDS  26 
JMP  ER 

JSR  SEMDIT 

LDA  0,  CR 

SKPBZ  TTOl 
JMP  .-1 
DOAS  0,  TTOl 


;Lo£jd  liyLCpoi  ntrr  Lo  file  QQVV 
;Load  (lofaull  i.iask 

;Open  file-  QQVV  on  cliannol  26 

;Load  pointer  to  bc^ginnin^,  of  Ul'D  :;torC' 
;Gct  the  'JFD  status  of  QQVV 

•,Nov;  calculate  the  size  of  QQVV 


;Load  tlie  site  of  file  QQVV 
;Load  the  sive  of  the  GETS  store 
•,Is  current  size  of  file  greater 
;than  size  of  CNTS? 

;No  -  read  QQVV  for  the  last  tir.e 

;Yes  -  read  at  least  t\;o  tiv.es 
;Load  bytepointer  tC)  buffer  CNTS 

;Read  a  portion  of  QQVV  ir.to  t'!.'j'S 

;Send  this  portion  our 

;Load  the  size  of  the  CNTS  buffer 
;and  the  current  size  of  QQVV  not  read 
;Find  the  difference  beL\;een  the- 
; two  and  store  in  SZOFFL 
;Return  to  read  the  next  portion 

;Load  the  bytepointer  to  CNTS 
;Load  the  current  size  of  QQVV 
; Store  this  size 

;Read  in  the  last  portion  of  QQVV 

;Send  this  portion  also 

;Load  a  carriage  return 

;lf  tlic  output  lino  i not  busy, 

;send  a  carria),e  retuni  as  the  last 
jcharaclcr 
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ONCE  COMPLETE,  CLOSE  AND  DELETE  QQVV 


TRYCLOS:LDA  0,  NAMOFFL 

.SYSTM 
•CLOSE  26 
JMP  CHKERR 

.SYSTM 
.DELET 
JMP  ER 

JMP  RETERN 

CHKERR:  LDA  1,  .ERFIU 
SUB  2,  1,  SNR 
JMP  TRYCLOS 
JMP  ER 

;  ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ER:  .SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  ER 

DEFINE  VARIABLES,  BYTEPOINTERS ,  AND  BUFFERS 


.ERFIU:  ERFIU  ;ERFIU  =  60,  file  in  use 

NAMOFFL: .+1*2  ;Bytepointer  to  file  QQW 

.TXT  "DPOF: DIALOG: QQVV" 

STRLOC:  UFDSTR 
UFDSTR:  . BLK  22 

SZOFFL:  0 
BYTSZ:  122 
PTRINIT:CNTS 
TEXTPTR : CNTS 
PTRCNTS:CNTS*2 
WRSSZ:  0 


;Pointer  to  UFD  store 
;18  decimal  UFD  word  store 

;Store  for  current  size  of  file 
;82  decimal  bytes  -  CNTS  buffer 
;Pointer  to  the  beginning  of  CNTS 
;Pointer  to  text  entries  for  CNTS 
;Bytepointer  to  CNTS  buffer 
;Number  of  bytes  to  be  written 


;Load  bytepointer  to  QQVV 
jClose  file  QQW 

;Check  to  see  if  there  is  an  expected 
;error 

;If  not,  delete  QQVV 

•,Then  return  to  the  calling  program 

;Is  QQVV  still  in  use? 

;Compare  to  error  code  ERFIU 

;Yes  -  return  to  try  tor  closing  again 

, Otherwise,  state  the  unexpected  error 
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CALCUI.ATF,  T1!K  FIZK  OF  QQVV 


CALCSZ:  FDA  3,  Zl'.RO 

LDA  1,  U)1)S7i:  +  lO 
SUfif-  3 ,  1  ,  SNR 
JMP  ADONCE 


;Loa(!  zero  (0) 

;Loa(i  the  number  of  the  last 
;block  in  QQVV.  Is  it  zero? 

;Ycs  -  just  calculate  once  the  size 


STA  1  ,  CtJTFR 
LUA  0,  ZERO 
LDA  2,  OK;'. BEK 


;Ko  -  load  the  number  of  blocks  in 
;countcr  and  load  zero 
;Load  the  size  of  one  block 


KULT:  ADD  2,  0 

DSZ  CETEU 
JKP  HUL'J' 


;Multiply  the  number  of  blocks 
;by  tlie  nur.iber  of  bytes  in  a  block 
;Continue  till  all  blocks  arc  included 


LDA  1,  UFDSTR-ill 
ADD  1  ,  0 
STA  0,  SZOFFL 
JMP  AGIJRD 


;Load  the  number  of  bytes  in  the 
;last  block  -  add  to  the  total 
;Store  total  in  size  of  file 
;Return  to  read  portions  of  QQVV 


ADONCE;  LDA  2,  UFDSTil+ll 
STA  2,  SZOFFL 
JMP  AGNRD 


;If  just  one  block,  store  the 
;ni)r;iber  of  bytes  in  size  of  file 
; Return  to  read  the  portions 


DEFINE  VARIABLES  AL’D  STORAGE  LOCATIONS 


ONE DLL:  1000 
ZERO;  0 
CUTER ;  0 

SAVES ;  0 

SAVE2;  0 
SAVEl  ;  0 

SAVLO ;  0 

SAVEC;  0 
CR ;  1  5 


;One  block  is  512  decimal  bytes 

;Countcr  storage  location 
•.Storage  location  for  accumulator 
;3,  2,  1,  0,  and  the  carry  bit 


;Carriagc  return  is  an  octal  15 
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SKiJD  Fil  l:  QQVV  OUT  C'lARACTFK  EY  CIIAKACTKR 


SEKDIT; 

;  STA  3; 

,  SAVE 3 

STA  1, 

,  SAVE2 

STA  1, 

,  SAVE] 

STA  0, 

,  SAVl-O 

MOVE  0,  0 

STA  0, 

,  SAVLC 

LDA  1, 

WRSSZ 

MOVZR 

1.  1 

STA  1, 

WRSSZ 

REPT : 

LDA  0, 

PTEXTPTR 

LDA  1  , 

MSK  i 

AKDS  1 

,  0 

SKPCZ 

TTOl 

JMP 

1 

DOAS  0 

,  TTOl 

LDA  0, 

0TEXTPTR 

LDA  1  , 

MSK  2 

AND  1, 

0 

SKPBZ 

TTOl 

JMP 

1 

DOAS  0 

,  TTOl 

i.DA  3, 

TL'XTPTR 

INC  3, 

3 

STA  3, 

TEXTPTR 

DSZ  WRSSZ 
JMP  RKPT 


LDA 

1, 

PTRINIT 

STA 

1, 

TEXTPTR 

LDA 

0, 

SAVEC 

MOVR  0 

.  0 

LDA 

0. 

SAVEO 

LDA 

1. 

SAVEl 

LDA 

2, 

SAVE2 

LDA 

3, 

SAVE3 

JMP 

0, 

3 

;Upon  cntCTina  rouLii.f,  store 
; accumulator G  and  carry  bit 


;Toad  number  of  bytes  to  write 
;Divide  tile  nuiaber  by  two,  as  two 
;bytes  will  bo  written  per  iteration 

;Load  pointer  to  text  character 
;Load  mask  to  isolate  left  byte 
jStrip  parity  and  swap 

;If  output  line  not  busy,  output 
;this  isolated  character 


;Load  same  text 

;Load  mask  to  isolate  right  byte 
;Strip  parity 

;Output  this  character  when  output 
;line  not  busy 


;Load  the  pointer  to  the  text 
;Increment  the  pointer 

;Have  the  words  all  been  sent? 

;No  -  return  and  repeat  for  the  next 
;word 

;Yes  -  load  the  pointer  to  beginning  of 
;text  buffer  -  CUTS 

;Restore  accumulators  and  carry 


jReturn  to  next  line  from  location 
;in  which  subroutine  called 
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DEFINE  MASKS 


MSKl:  177400 

MSK2:  000377 


RETERN:  JSR  (?  .FRET 

;  DEFINE  CONTENTS  BUFFER 

>  —  —  —  —  —  —  —  —  —  —  —  — 

CKTS ;  .BLK  122  ;82  decimal  bytes  of  storage 

FS.=0 

TMP=-167 

.END  GET FIDE 


;Mask  to  isolate  loft  byte 
;Mask  to  isolate  right  byte 


END  GETFII.E.SR 


oorjooooooo 


c - 

e - 

c 

c  ++  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
c  +  + 

C  +  RKADYREAD.rR  + 

C  +  *■— *  CREATED  9  AUGUST  1980;  REV  00  + 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

c 

C - 

c 

c 

C  rrogrnm  READYREAD.FR  is  cal loci  by  KORITOR.RR  and  returns  to 

C  MONITOR,  whenever  a  disk  file  needs  to  be  prepared  (i.e., 

C  created)  to  accept  data  froin  the  "system."  File  VVQQ  is  created 

C  to  receive  the  data  from  the  "systera",  which  will  transpire  on  the 

C  next  execution  of  task  call  SYSIN.Sk.  This  latter  action  is 

C  triggered  by  a  repeated  call  to  open  the  file  VVQQ,  which  only 

C  succeeds  after  VVQQ  has  been  created.  The  call  to  READYREAU 

C  is  as  follov/s: 

CALL  RKADYREAD  ($602) 

The  $602  is  the  return  line  number  in  MONITOR  that  will  next 
be  executed  upon  return  from  RKADYREAD. 


k'>\ 
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**  READYREAD  receives  an  assigned  dummy  return  variable.  ** 

SUBROUTINE  READYREAD  (15DUMRTN) 

**  This  call  creates  file  VVQQ,  that  will  be  accepting  data  ** 
from  the  "system."  Data  will  actually  be  entered  only  when 
WQQ  is  opened  by  SYSIN.SR. 

CALL  CFILW  ("DPOF:DIALOG:VVQQ",2,IERR1) 

IF  (lERRl  .NE.  1)  TYPE  "lERRl  IS  ",  lERRl 

**  Return  to  the  statement  number  passed  in  I5DUMRTN.  ** 

RETURN  I5DUMRTN 
END 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


END  READYREAD.fr 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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c 

C' 

c 


c 

c 


c 

c 

c 

c 

c 

c- 

c- 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c- 

c- 


+  +  +  ^  +  +  ^-  +  +  ^■  +  +  +  +  +  +  +  +  +  ^+  +  +  +  +  +  + 
+  + 

+  Rtxrvi'n  E.FR  + 

+  CREATED  9  AUGUST  1980;  REV  00  ****+ 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  j 


ProRrani  RECEVFILE.FR  is  called  by  f'OIlITOR.FK  and  returns  to 
MONITOR,  whenever  a  command  sequence  from  an  action  file 
requires  a  "local"  disk  file  to  be  created  to  receive  data 
transiTiitled  from  the  "system."  RECEVFILE  uses  the  RDOS  file 
CLI.CiI  to  "send"  action  file  commands  to  the  "local"  system. 
Thus,  tlie  action  file  command  is  inserted  into  CLI.CM  and  then 
a  program  swap  takes  place  to  execute  that  cormiand.  When 
swapping  taker,  place,  functions  within  tasks  are  disabled 
(sucli  as  .IDLF).  Therefore,  the  task  SYSIK  is  inactivated 
(killed)  and  reactivated  before  and  after  the  swap  -  program 
EXCLI.SR.  Lastly,  RECEVFILE  deletes  the  temporary  disk  file 
VVQQ,  as  it  is  no  longer  needed.  The  call  to  RECEVFILE  is  as 
follows ; 


CALL  RECEVFILE  (  l.ACTFILE.MDIMl ,  $602) 

lACTFILE  is  on<-  line  from  the  action  file  that  is  to  be 
acted  upon  by  the  "local"  system.  MUIMl  is  the  size  of  the 
one-dimcntional  arrray  lACTFlLE,  and  $502  is  the  return  line 
number  in  MONITOR  Lliat  will  be  next  executed  upon  return  from 
RECEVFILE.  All  parameters  are  passed  from  MONITOR  to  RECEVFILE. 
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n  o 


c 

C  RKCEVJOLi;  receives  an  input  array,  tlio  dimension  of  that 

C  array,  and  an  assijjned  duiimiy  return  variable. 

C 

SUBROUTINE  RIXEVFILC  (  INf.ARRAY ,  I6D1MAR ,  16DUURTU ) 

C 

C  SYSIN.SR  is  the  task  program  that  monitors  "system"  input 

C  and  v/as  activated  by  MONITOR.  As  it  is  to  be  killed  and  then 

C  reactivated,  DG  FORTRAN  requires  that  it  be  externally  defined. 

C 

EXTERNAL  SYS  IN 

DIMENSION  Ii:6ARR.\Y(l6DIf!AR) 

C 

C  **  Tliis  call  creates  file  CLI.CH.  If  it  already  exists,  an  ** 
C  error  of  12  is  returned  in  JERRI.  If  the  call  is  okay,  an 

C  error  of  1  is  returned.  Any  other  error  is  printed  out  for 

C  reference.  This  insures  that  CLI.CH  is  available. 

C 

CALL  CFILU  ("CLI.CH", 2, JERRI) 

IF  (JERRI  .NE.  1  .AND.  JERRI  .NE.  12)  TYPE  "JERRI  IS  ",  JERRI 
C 

C  **  This  call  opens  file  CLI.CH  on  channel  25.  State  the  error  ** 
C  condition  if  not  opened  properly. 

C 

CALL  OPEN  (25,"CLT.CM",2,JERR2,82) 

IF  (JERR2  .NE.  1)  TYPE  "JERR2  IS  ",  JERR2 

**  Insert  command  sequence  from  action  file  into  CLI.CH.  ** 

C 

WRITE  (25,6001)  ( 1N6ARRAY(L1 ) ,  LI  =  3 ,  I6DIMAR) 

6001  F0R1L4T  (IH  ,  80A1 ) 

C 

C  **  Close  CLI.CH  so  it  can  be  deleted  in  EXCLI.SR,  after  it  is 
C  no  longer  needed. 

C 

CALL  CLOSE  (25,JERR3) 

IF  (JERR3  .NE.  1)  TYPE  "JERR3  IS  ",  JERR3 
C 


oooooooooooo  noo 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 


C 

C 

C 

C 


**  Before  executing  the  swap  (EXCLI),  inactivate  SfSIN.  ** 

SYSIN  is  the  only  task,  with  priority  one  (1). 

CALL  AKILL(l) 

**  EXCLI  swaps  to  level  two  (2)  to  execute  the  instruction  ** 
just  inserted  into  CLI.CM.  Level  two  (2)  is  the  RDOS  CLI. 

Upon  completion  of  the  swapped  program,  control  returns  to  the 
next  instruction  in  this  program. 

CALL  EXCLI 

**  Reactivate  SYSIN  just  as  it  was  before  the  swap.  ** 

CALL  ITASK  ( SYSIN , 10 , 1 ,JERR4, 1 ) 

IF  (JERR4  .NE.  1)  TYPE  "JERR4  IS  ",  JERR4 

**  Upon  return  from  the  swap,  delete  file  VVQQ,  as  it  is  no  ** 
longer  required. 

CALL  DFILW  ( "DPOF : DIALOG : VVQQ" , JERR5) 

IF  (JERR5  .NE.  1)  TYPE  "JERR5  IS  ",  JERR5 


**  Return  to  the  statement  number  passed  in  I6DUMRTN. 


RETURN  I6DUMRTN 
END 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 


+ 


END  RECEVFILE.fr 


+ 


+  + 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  t  +  +  +  +  +  +  +  +  +  +  + 
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+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  4  ^  +  + 


+  + 

+  toti:k!I.sr  + 

+  CHEATED  27  JUNE  19r.O;  REV  02  + 

+  + 


+  +  +  +  +  +  +  +  +  +  +  +  +  4  +  4  4  >4  4  4-+4-4-+4-4- 


"Jc  -J:  'k  k  k  k  k  k  k  k 

Progrnm  TOTPKM.SR  is  called  fron  MOIilTOR.FR  ai'.d  alvays  calls 
TidlMOP.SR  in  turn.  This  pro^^ra”;  transitions  the  user  Irori  Llie 
MOIJITOU  Command  Lan,_,ua,',e  to  the  transparent  Lerninal  only  mode. 

The  transition  is  effected  vtlierovcr  the  user  enters  "'T"  anyv/lierc 
in  the  ronr.iand  line  after  IIOMTJ'OR  provides  its  loronpt  .  Th.o 
program,  in  addition  to  junpin:’  to  TUFdlO!’ .  Sh ,  also  removes  the 
"system"  device  codes  that  were  identified  (via  .IDhF)  in  SVSIl.'.SR. 
This  is  nocessa.ry,  since  TErd.OP  identifies  its  own  device  codes. 
Both  TllRIlOP  and  SYSIN  use  the  same  device  codes  —  $TT01  and  S'i'TTl. 
There  are  no  ar£,usicnts  or  parameters  that  are  passed  via  TOTilRj'i. 

kkkkkk kkk k 


.TITL  TOTERM 
.EMT  TOTEi.M 


.E.KTD  TERMOP 


.TXTM  1 
.EXTU 

•EXTN  .1 


•,Prog,ram  name  -  To  Terminal  Operation 

;Enablrs  o''  Me  entry  into  this 
; program 

;Dcc'  ,s  program  name  (address) 
;TERKOP.SR  as  external  displacement 
;TERKOP  can  now  be  accessed  by  TOTERM 

;Packs  ASCII  strings  left  to  right 

jUndefined  variables  are  treated 
;as  External  Displace., lent  variables 

•  ;Providos  some  FORTRj'd..’  initialization 


» 
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.ZKI.l, 


;Zeio  rclocr'tablo  space  sLarls 


.KR:  KRR 

.TOTRK!!:T1:R!;oP 


;Acccss  to  ERR  and  TERMOR  nay  be 
;gainGcl  via  indirect  addressing  to 
;thcsc  locations 


•NREL  ;Norraai  relocatable  space  starts 

FS. 

FIRST  REMOVE  IbEET J  E I  ED  [lEVlCE  CODES 


TfiTERlMJSR  C  .FARE 

EDA  0,  DJCODE 
. SYSTM 
.IRKV 
JMP  Clir.i.R 


EDA  0,  DZeOUE 
.SYSTM 
•  IRMV 
JMP  CHKER 


JUMP  TO  TFRIIOP.SR 


JMP  0  .TOIERN 


;Load  device  code  for  $TTI1 

jReiiove  it  iron  the  "systen" 

;If  ;ni  error,  check  to  see  if 
;devicc  tins  already  been  removed 

;Load  device  code  STTOl 

;R(;move  it  from  the  "systen" 

;If  an  error,  check  to  see  if 
;device  has  already  been  removed 


ROUTIEE  TO  CHECK  FOR  EXPECTED  ERROR 


CHKER: 

ERA 

1, 

. ERDNM 

;Has  device 

been  removed? 

SUB 

2, 

I  ,  SNR 

JMP 

0 

.TOTEKM 

;Yes  -  jump 

to  TERMOP 

JMP 

0 

.  ER 

•,Ho  -  state 

the  abnormal  error 

ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALEY 


ERR;  .SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  @  .ER 
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VARTAIJLI'S  DEFINED 


.ERDKM:  ERDNM 

DICODE:  TTIl 
D2COI)I.:  TTOl 


;ERI)Nn  =  36,  device;  not  in  cysLeiii  error 

;$TT01  it  the  first  device  code 
; $TTOi  is  the  second  device  code 


JSR  @  .FRET 


FS.=0 

TMP=-167 


.END  TOTERM 


+  +  +  +  +  +  +  +  +  +  +  H  +  +  +  +  +  +  +  +  +  +  H  +  +  +  + 
^  + 
■i  END  TOTERM.SR  + 
+  + 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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+  H  +  +  +  +  +  +  +  +  -(  ^  +■f++■^+^  +  +  +  +  ^  -^  +  + 


+  + 

^  TKRMOP.SR  + 

4  **-■*  CREATED  30  JU1!E  ]  080 ;  REV  02  *-■**  + 

+  + 


+  +  +  4  +  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


Prop,ro:n  TEREiOP.SR  i?  called  by  TOTl'R^'. .  SR ,  vliicli  is  called  fror. 
KONITOIJ.FPw  TE)!!iOP  i.R  the  Lcrr.i  nn  1  only  mode  ol  ojjcaatic'ii  lor 
intciconir.uni  cat:  i  un  \jith  tlie  "sysLi.-n."  Trow  Elio  "local" 
tcrniiial  ,  the  mode  of  operation  is  as  a  transparenl  Leriiiiiial 
connected  to  tlie  "sy  r.t  cm . "  TERl'.OP  serves  as  a  device  driver 
tiiat  cnablcG  intercofj.iunicat  ion  betv.'ccn  the  "local" 
systeia  (d(.vit('s  $TTO  and  5'iTI)  and  a  "system"  connected  to  it 
via  devices  (devices  $TT01  and  $T'fll). 


•TITL  TERKOP 
,EXTN  .TASK 

,ENT  TERMOP 

.TXTM  1 
.  EXTU 


.EXTK  .1 


•jProgram  name  -  Tei-minal  Operation 

;PennitR  prof^ram  to  externally 
;acc.ess  task  call  TASK 

•.Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

jUndefined  varaibles  are  treated  as 
jExtornal  Displacement  variables 

•.Provides  some  FORTRAN  initialization 
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•,Zero  ve  1  oc- aV  abl 0  spaci,'  sLartf; 


.ZKFL 

.EU: 

.KOYl:  NdTEl 

.r;0T2:  KH)'n:2 


.KRl'l, 


;AcccPS  Lo  KKHOli  am'  i.'f'T!  1 
;inay  be  pained  via  indirect 
; addres:  ing,  to  these,  locations 


;Kc)tTiial  roloccitable  space  starts 


DEVICE  CfiETHOL  TAULE  (DOT)  l^xYOUT 


A1 DCT: 

Till AD 

A 2 DCT: 

TTOl AD 

TTll AD: 

ETA ISA 
-1 

Till  IDA 

TTOl AD: 

STA2SA 

-1 

TTOl DA 

AUDITlOliAL  VAUIAISEES  FOR  $TTI1/$TT0.1 


01  CODE: 

TTll 

D2C01)E: 

TTOl 

STAISA: 

.BLK 

10 

STA2SA: 

.BLR 

10 

;Addrras  of  TTll  DOT 
jAddress  of  TTOl  DCT 

;Ii'.Lorrupt  state  sacc  area  -  TTll 
;na.‘d;  v;ord  for  no  interrupls 
;TTI1  interrupt  sereico  routine 
;  a  d  d  r  e  a  s 

; Interrupt  state  save  area  -  TTOl 
;lfask  word 

;TTC)1  interrupt  service  routine 
;addrcss 

HANDLERS 


;  Dev  ice  code  -  TTI  .l 
;Devicc  code  TTOl 

;Eight  v;ord  state  save  area  -  TTll 
;Same  --  TTOl 


1G9 


START  0!'  TRKRir.AI.  0P!;);AT)0:;  !>ia>GJ;A;; 

rs. 

;I.oad  default  na^-.k 
;Load  by tt-jiointer  to  KOTKl 

; Write  tlOTEl  to  TTO 

LdFINT,  ULVICES  $TTI1/STT01 


TERROR :  JRR  C‘  .RARE 


SUb  ] ,  1 
ETA  0.  C-.NOTl 
.SYRTM 
.V.'RL  21 
JMP  0  .1-R 


DEF1DEV;LDA  0, 

D1  CODE 

;I)efine  TTl  1  via  tbe  .IDEF 

Li>A  1  , 

AIDCT 

;call,  using  device  code 

.SYSTM 

;TTI1  and  its  DCT  address 

.  IDF.F 

JMP  C 

.ER 

DEF2I)EV:LI)A  0, 

D 2 CODE 

;Dcfine  TTCI  via  the  .IDEF 

LDA  1  , 

A2DCT 

;call,  using  device  code  TTOl 

.SYSTM 

;and  its  DCT  nddress 

.IDEE 

JMP  e 

.ER 

DEFTRE  LI1.T.RD  AS  AN  ASYNCHRONOUS  TASK 


DEFTASK;1,I)A  0,  II'ANDPR 
LDA  ] ,  TSKPTR 
.TASK 
JIIP  U  .ER 

;  DEVICES  STTH/sSTTOI  DEFORE 


;Load  the  ID  and  prior i.y  of 
;task  LIKERD;  load  task  pointer 
;to  LINLRD 


START] NG 


NIOC  TTIl 
NIOC  TTOl 
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Fl.Uvr  TASK  —  R'i'.M)  AKO  \;R]TF,  CllAIlACTK KF  1'K()M/T0  TT]  AM)  TTO 


Tr.Kr.iAi:  .SYSTM 
.GCHAii 
JMP  ij  .KR 
.SYS'l'i: 

.  PCFA}’, 

JMP  0  .i:r 

LDA  .1  ,  UPAROW 
SUIA-  0,  1,  SI^R 
JMP  LVJ'RMOP 

SKPbZ  YTOl 
JMP  .-1 
nOAS  0,  TTOl 

JMP  vi-Rfn:n 

LVTRi;OP;LDA  0,  C-  .NOT2 
SUB  ] ,  1 
.SYSTM 
.V.'RL  21 
JMP  0  .FR 

;  ROUTINE  TO  RETL'hU  TO  THL  CLl  K 


;Gct  characlor  froi,'  TTI 

jPut  cliarnf.t(;r  Lo  TTO 


•jCoinp.ire  charac tor  to  ; 

;If  ;i  inaLcli,  return  to 
;thG  CLI.  Otliorx.'i  HG  , 

; out  put  tho  character  Lo  TTOl 


jRcturn  to  tertiiiiial  read/vr Ite 


lUWLLY 


.SYSTM 

.RTM  jKormal  return  -  no  error 

JMP  C  .F,R 


DLEIM'  AI)1iITIO!:AE  VARIAKIJ'S  USED  ABOVE 


IDAE'DPR:  10B7  +  10 

TSkPTH:  I,ir;ERD 
UPAltO;,':  .TXT  "<0>"" 


jI.INERl)  ID  ia  ten  (arbitrary); 
;priority  is  also  ten  (arbitrary) 

; Second  tasl;  is  LII.’KRD 

;PCUAK  and  CCHAiR  zero  out  the  left 
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Ht-CO'.-Ji  TAS':  —  rj-All  AKD  WRlTi:  Ki;o;:/TO  A!.'!)  $TT()] 


This  routine  operates  on  a  f i r s t -i n/ f i r s t-out  huff<'r  concept. 

A  sin^^e  buffer  is  defined  (hlJl'F)  that  is  i33  character;. 

Ion}'.  (f.'Oii;;  'file  buffer  is  133  v/orchs  Jonr,  but  each  ■..'ord 
contains  Just  (>iie  character  due  to  tb.e  vay  the  reads  arid 
writes  pack  A.SCIl  strinijS.)  Tv/o  pointc-rs  are  defined  to 
keep  track  of  the  latei.t  char.-'cter  entered  (ib'i-'T)!)  and  the 
latest  clinractc  r  exited  (OUTP'l'r;)  .  A  third  pointer  (Cillii’TlO 
always  renains  at  the  h(:r,innii;};  of  the  buffer  and  is  used  for 
initialization,  cdien  retjuired'.  A  fourtli  [jointer  (MAaI’jT,)  is  used  to 
insure  tlie  buffei  lcn;}th  is  not  e-.rceedtjd  wlu.n  enterin';  and 
exitin;;  charncti-rs.  P  icLor  i  .il  1  y  ,  thi;;  locks  as  fo]io\;r.: 


BUFPKR  "bUl'F" 


CUTPTR 

\/ 


+  +  +  H  ++  +  +  4 


1 

I 

!  BUFF 


1 

! 

BUFF-H  !  BUFF+2 


++  +  ■1  -I  f  ■ 

/\ 


+  +  +  +  +  +  4-  +  +  ^  + 


CIIKPTR 


ll/iXPTR 

\/ 

/  +  +  +H  +  +  +  4-M  +4  +  +  -I -I +  +  +  +  +  +  4  4  4  4  4 

/  !  !  !  ! 

/  .'  !  !  ! 

/  1BU1F4131  !BUFFrl32  Ik.Ul  1-4133  ! 

/  44-i 444  4^  T  44*i' H‘H  'i-4  v'J--M-4  T  4  4  4  4  4  4 

/\ 

IKl'TR 


hlKERD:  l.DA  1,  IRPTR 
LDA  2,  OUTPTP. 
SUB#  2,  1,  StlR 
JKP  LIR’FRD 

I.DA  0,  0OUTPTR 
. SYSYM 
.PCHAR 
JMP  @  .FR 

IRC  2,  2 
LDA  3,  MAXPTR 
SUB#  2,  3,  SNR 
JMP  INITl 
STA  2,  OUTPTR 
JMP  LINERD 

IRTTl:  LDA  2,  CHKPTR 
JMP  I  KIT] -2 


•jCompare  in  and  out  pointers 
;Tf  they  are  the  sane,  there  are 
;no  further  characters  to  print 
;Retnrn  to  the  line  reader 

;Othcr\/ife,  output  to  TTO  the 
;contc'nts  of  IdJEF  pointed  to  by 
; OUTFTR 


;Conipare  OUTPTR41  and  MAXPTR 
;If  they  arc  the  sarv.',  jump 
;to  routine  to  re- in i t  j a  1  ize 
;OUTP'iR  \/itii  the  CilRPYR.  Otlierwise, 
jstoro  new  value  of  OU’IPTR 
;and  return  to  the  line  reader 

;Re-initia] ize  OUTPTR  by  storing 
jvalue  of  CHKPTR  in  OUTPTR 
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ADDlTKlIwM.  1'01;;:'1R  Ai;i)  cask  VAliTABLES  DKl-IKKI) 


NOT El  : 

.  +  1*2 

jBytepointer  to  NOTEl  message 

.TXT  "You 

hav  e 

enterivl  into  tlie  terminal  only  mode.  Proceed  !  <1 5>" 

N0TE2 : 

.  +  1*2 

.TXT  "You 

have 

returned  to  the  local  CLI  r;ode!<15>" 

OUTFTH: 

BUl'F 

; Initialize  pointers  to 

INPTR; 

BUFF 

•,beginning  of  buffer  BUFF 

CHKt’TK  : 

BUFF 

PKSK  : 

177 

;Mask  to  strip  parity  bit 

$TT11  liNTERRUI'T  SERVICE  ROUTIIiE 


TTIIKA:  STA  3,  USP 

STA  2,  SAVE2 
STA  1,  SAVEl 
STA  0,  SAVEO 
MOVE  0,  0 
STA  0,  SAVEC 

DIAC  0,  TTll 
EDA  3,  PMSK 
AND  3,  0 
STA  0,  C'lKPTR 

EDA  1,  INPTR 
INC  1,  1 
EDA  2,  MAXPTR 
SUB#  1 ,  2 ,  SMR 
JMP  CHECK 
STA  1,  INPTR 

RETURN:  EDA  0,  SAVEC 
MOVU  0,  0 
EDA  0,  SAVEO 
EDA  1 ,  SAVEl 
EDA  2,  SAVE2 
EDA  3,  USP 
JMP  0,  3 

CHECK:  EDA  3,  OUTPTR 
EDA  2,  CMKPTR 
SUB#  2,  3,  SNR 
JMP  PROBl 


STA  2,  INPTR 
JHP  RETURN 

HAET 


;Save  the  previous  processor 
;state  by  saving  nil  accumulators 
;and  the  carry  bit.  USP  is  the 
;User  Stack  Pointer,  location 
;016  (octal) 


Input  the  diameter  from  TTIl  to 
accumulator  zero,  and  strip  the 
the  parity  bit  in  the  right  byte 
Put  character  in  next  empty 
buffer  location 

Is  the  INPTR  at  the  end  of  BUFF? 
Increment  INPTR  to  compare  with 
MAXPTR.  If  they  are  tlie  same, 
jump  to  check  the  location  of 
OUTPTR.  Otherv/isc, 
store  the  new  value  of  INPTR 

Restore  the  state  of  the  processor 
before  returning  to  the  next 
instruction  in  the  program 
interrupted  by  input  from  TTIl 
(This  could  be  cither  of  the 
two  tasks  of  TEPdlCP) 


•,If  outptr  is  still  at  tlie 
;beginning  of  the  buffer  BUFF, 

; there  is  a  buffer  overflow 
;potential  requiring  the  processor 
;to  halt!  Othcrv/isc, 

;store  the  new  value  of  INPTR 
;and  then  return 

;Not  a  recoverable  errror  - 


PROBl : 


STOP! 


$TTol  iK'n:!ua'i’T  sr.RViCE  routi:;e 


h 


TTOlRA:  KIOC  TTOl  ;Idle  the  device  TTOl  end 

JMP  0,  3  ;return.  No  need  to  save  the 

;the  processor  state,  as  it  is 
;not  changed 

;  ROUTINh  TO  RETURN  TO  TiiK  CLI  ATNORUALLY 


ERROR:  .SYSTI1 

.ERTN  ;Abnorrial  return  -  error 

JMP  e  .ER 


DEFINE  NECESSARY  STORAGE  AREAS  TO  BE  USED 


SAVED ;  0 

SAVEl  ;  0 

SAVE2:  0 
SAVEC:  0 
Mi/^XPIR:  BUFril33. 
BUFF:  .BEK  133. 


;Proccssor  save  state 
; 1 ocat ions 


;Pointer  to  the  end  of  BUFF 
;BUFF  is  133  v;ords  long  (decimal) 


JSR  D  .FRET 

FS.=0 

TMP^’-IC? 

.END  TERMOP 

j  ; 

'  ;  +  +  +  +  +  +  +  4+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

;  +  + 

;  +  END  TERMOP. SR  + 

;  +  + 

;  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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■*  *  *  V:  Vc  Vr  -k  k  k  k 

Proj'.rans  SYSI!;.SR  i  r,  an  asyncbroncnis  tasV.  that  is  activated  via 
task  calls  and  inactivated  via  task,  calls.  Initially,  SYSI’i  i.s 
activated  by  .YOdl’l  (>); .  FK  .  It  is  .sulnsc  queiit  1  y  3  nac  t  i  va  t  fc!  and 
reactivated  by  SrhbF  I  Lb  .  FR  and  LFCi.Vi  i  LI  .  x  il .  MOLIlOi’  .also 
inactivate.s  SYSIK  just  lofcre  sbiftinc,  to  Lkie  terninal  oiily 
Hiodc  of  operation.  SYBIL  does  .scverxil  tiiint.s  ;>  iirul  t.aneou  1  y  . 
Fir.st,  it  defiixos  device  codes  STKjI  and,  f'l'TIl  tiiat  are  not 
systera  generated.  Second,  SYSlii  reads  tin-  input,  line  froiX:  tbex 
"system"  -  $TTI1  -  after  tiux  device  defined  iixtcrrupt  routiner, 
store  tbe  input  in  a  buffer.  Third,  SYSIL  readies  task  liOI.'lIO!; 
whenever  it  is  su.sjiendcd .  And  fourth,  SYBIL  v.n'ites  to  file 
VVQQ  vdicnever  it  is  created  by  program  P.LCFVl'l  l.i, .  SYS  I’:  is  of 
priority  1,  wiiich  is  lover  in  precedcxxice  than  MOLITOk,  \;liich  is 
of  priority  0.  SYSIK  also  has  tlio  identity  numbe.r  iO.  As 
SYSIK  is  not  a  subroutine,  there  are  no  arginncnts  or  parameters 
that  are  passed  via  SYSIK. 

kkkkkkkkkk 


.TITL  SYSIK  iProgram  name  -  System  Input 

.ENT  SYSIK  •,Enables  outside  entry  into  this 

; program 

.EXTD  .BUFl,  .BUr2,  .FBI,  .FB2  jTbese  storage  locations  were  created 

;by  CKVRT.SR  and  must  be  acces.sed  by 
;SYSliN.  They  are  external  displacements 

.EXTN  .ARDY  ; .ARDY  readies  suspended  tasks  and 

jmust  be  declared  external  normal 

.TXTM  1  jPacks  ASCII  strings  left  to  right 

.EXTU  jUndefinod  variables  are  treated  as 

;External  Displacement  variables 
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ZREL 


;Zero  relocatable  space  starts 


.ER;  ERR 


;ERR  may  be  addressed  indirectly 
;via  this  location 


■i 


9 

.NREL 

;Normal  relocatable  space  starts 

9 

DEVICE  CONTROL  TABLE 

LAYOUT 

DlDCT 

:  HAD 

;Address  of  $TTH  DCT 

D2DCT 

:  OlAD 

;Address  of  $TT01  DCT 

HAD: 

SSAl 

;Interrupt  state  save  area  -  $TTH 

-1 

;Ma6k  word  for  no  interrupts 

HRA 

;$TTH  interrupt  service  routine  addres; 

OlAD: 

SSA2 

;lnterrupt  state  save  area  -  STTOl 

-1 

;Ma6k  word 

OIRA 

;$TT01  interrupt  service  routine  addres 

9 

9 

ADDITIONAL  VARAIBLES 

FOR  $TTH/$TT01  HANDLERS 

CODEl 

:  TTH 

;Device  code  -  $TTH 

C0DE2 

:  TTOl 

;Device  code  -  $TT01 

SSAl : 

.BLK  10 

;8  decimal  word  state  save  areas 

SSA2: 

•BLK  10 

9 

9 

DEFINE  BYTEPOINTER  AND  NULL  WORD 

TMPFL 

:  .+1*2 

;Bytepointer  to  file  VVQQ 

.TXT  "DPOF:DIALOG 

:VVQQ'' 

NULL: 

0 

;A  null  word 

9 

9 

DEFINE  THE  DEVICES 

SYSIN 

:  SUB  1,  1 

;This  is  no  operation  -  holds  a  place 

DEVI: 

LDA  0,  CODEl 

•.Define  $TTH  via  the  .IDEF  call, 

LDA  1,  DlDCT 

;using  device  code  $TTH  and  its 

.SYSTM 

:DCT  address 

.IDEF 

JMP  @  .ER 

DEV2: 

LDA  0,  CODE2 

;Define  $TTOl  via  the  .IDEF  call, 

LDA  1,  D2DCT 

;uBing  device  code  STTOl  and  its 

.SYSTM 

;DCT  address 

.IDEF 

JMP  @  .ER 
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DEFINE  AN  ASYNCIIKOKOUS  TASK  TO  KEAD  LIKE  INPUT 


SET: 


RSETl : 


1.DA 

1. 

INPTR 

EDA 

2, 

OUTPTPv 

SUBi- 

2 

,  1  ,  SDK 

JMP 

CllKDLAY 

LDA 

1. 

DLAYCl.'T 

STA 

1. 

CUTER 

.MINE 

;  I! 

!PUT 

LDA 

0. 

PCUTFTR 

INC 

2. 

2 

LDA 

3. 

MAXPTR 

SUBi; 

^  2; 

,  3,  SNR 

JMP 

RSETl 

STA 

2, 

OUTPTC 

LDA 

3, 

MILL 

SUB# 

3 

,  0,  SNR 

JMP 

RDLINE 

STA 

0, 

GMATPTR 

LDA 

3, 

HATPTR 

STA 

3, 

FMATBUF 

LDA 

1, 

LF 

SUB# 

■  0 

,  1  ,  SNR 

JMP 

cot 

IPAR 

LDA 

1, 

CR 

SUB# 

^  0 

,  1  ,  SNR 

JMP 

CO! 

IPAR 

INC 

3, 

3 

STA 

3, 

MATPTR 

JMP 

RDLINE 

LDA 

2. 

CUKPTR 

JMP 

SET 

;Conipare  in  and  out  pointers.  If 
jtliey  are  t’ne  same,  there:  arc  no  further 
;charactcrs  from  input 
;Check  a  delay  time-out  before 
^readying  task  I'OKITOR 

;Otheri;ise ,  insure  time-out  parameters 
; are  reset  and  initialized 


;Load  the  contents  of  outptr 

jincrement  the  outpointer  itself 
;Load  the  maxpointer  and  compare  to 
;outpointer.  If  they're  equal, 

•.reset  pointer  to  beginning  of  buffer 

;0thcr\i7ise ,  give  outpointer  a  new  value 

;Load  .1  null  \)ord 

;Is  the  character  a  null?(Input) 

;Yes  -  tiirow  it  av;ay  and  get  next  one 

;No  -  store  character  in  Match  Buffer 
;Save  this  location  in  Full  Match  Buffer 

;Is  character  a  line  feed? 

;Yes  -  compare  all  of  Match  Buffer 

;No  -  Is  character  a  carriage  return? 

;Yes  -  compare  all  of  Match  Buffer 

;No  -  increment  the  match  buffer  pointer 

;Store  the  new  value 

;Return  to  get  next  input  character 

;If  outpointer  is  at  the  end  of 
;its  buffer,  reset  to  the  beginning 
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AFTi:n  A  OKi.AY  'J'l MK-OIJT,  HKADY  KONJTOK 


REDYTSRrl.DA  I,  MATITR 
L.DA  2,  MATSTR'i 
Sl'F,;-  2,  ],  SZK 
JUP  COMPAR 

.SY’STM 
.CLOSE  27 
JMP  .+1 

EDA  0,  TSEPKl 
.ARDY 

JMP  RDl.TKE 

;  DELAY  BLrORE  READYIXG  MOEITOK 


CURDL7iY;DSZ  CLTER 
JMP  ULAY 
LDA  1  ,  DI.AYCKT 
STA  1 ,  CKTER 
JHP  REDYTSK 

Dl.AY  :  LDA  ,l  ,  PUL  SC 

.SYSTM 
.DELAY 
JMP  @  .ER 

JMP  RDLIKE 

;  DEFItlE  VARIABLES  AND  BUFFERS 


PULSC:  3 
CUTER:  32 

DLAYrr:T:32 
TSF.PRI:  0 

MATPTR:  MiA.TBUFR 
KATSTRTrMATBUFR 
FMATBUF:0 

RSPSZ:  0 

LF:  12 

CR:  15 

PHSK:  177 


;Insuro  nolhiir;  is  in  Llic  mnLcii  iMiffcr 
;If  son.cLliing  is  tlicrc,  cor.. pare  ihe 
;cnLire  buffer 

;lf  not,  then 
; close  file  VVQQ 

;If  already  clor.ed,  just  continue 

;Load  the  priority  of  MOUITOR 
;i:eady  KOMITOR 

;Return  to  p^et  next  cl/aractcr 


;Dccreir,ent  the  counter  -  if  not  aero 

;dolay  a  while  longer 

;Otherwise,  reset  delay  values  and 

;allow  MONITOR  to  take  control 

;Load  the  nuiabcr  of  pulse  counts 

;Dclay  processing  for  the  time  allotted 

; Return  to  check  the  input  again 


;3  decimal  counts  —  3/10  sec 
;Initial  count  is  26  decimal 
;This  creates  a  7-1/2  sec  delay 
;MONITOR's  task  priority  is  0 

;A  pointer  to  start  of  Match  Buffer 
;  Same 

;Location  of  a  full  Match  Buffer 

;TeMporary  location  to  store  size  of 
; responses  gathered  fron  CilVRT.SR 
;Line  feed  is  an  octal  12 
;Carriage  return  is  r.n  octal  15 
;Mask  to  strip  parity  bit 
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i 

I 

I 


LOOK  AT  Tin;  MATCH  BUJTr.R  AMD  COMPAUK  TO  KXPKCTLD  KLKPOi.'SLS 


COMPAR:  LDA  0,  IL\TSTRT 
LDA  1,  .Fl’.l 
LDA  2,  .liUFl 
STA  1 ,  RCrSZ 

CPP.L'.c;:  STA  0,  MA'l  PTR 
LDA  0,  O'MATPTR 
LDA  3,  0,  2 
RUK#  0,  3.  SLR 
JMP  CMPRl 

LDA  0,  MATSTRT 
LDA  1,  .FB2 
LDA  2,  .EIIF2 
STA  1 ,  RSPSZ 

CPR2AG:  STA  0,  JWTPTR 
LDA  0,  GMATPTR 
LDA  3,  0,  2 
SUBP  0,  3,  SLR 
JMP  CMPR2 

;  OPEL  VVQQ  IF  IT  HAS  BEEH  CREATED 


LDA  0,  IMPEL 
SUB  1,  1 
.SYSTM 
.OPEL  27 
JMP  ERCHK 
JMP  URTOFL-1 


;Load  start  of  Hatch  Buffer 
;Load  size  of  first  response  ex[)ected 
;Load  starting  location  of  first 
;responsc  buffer.  Store  size 

•.After  setting  pointer, 

;get  the  character  input 

;Oet  first  character  of  response  buffer 

‘.Are  they  the  saiaiT 

;Y’es  -  reset  values  to  check  next  input 

;Lo  -  start  at  the  buffer  beginning 
;Load  size  of  second  expected  response 
;Load  start  of  second  response  buffer 
•.Store  size 

;Look  at  characters  just  as  before 


•.Load  bytepointer  to  file  VVQQ 
;Load  the  default  mask 

;Open  VVQQ  on  channel  27 
jCheck  for  expected  error  condition 
;Lf  no  error,  then  begin  output  of 
;file  VVQQ  to  "system" 
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ouTi'iiT  r;:i:xrr(:'i;,!)  ursi cxsks  to  tkioiinai,  scni’i;:: 


LDA  1 ,  ;tA’lSTi;T 


OUTPrr:  PTA  1, 

LDA  0,  D.'T.'il'TR 
. SYDTM 
.PCl'.Ai; 

JMP  (,  .LP. 

LDA  lOV  i.UF 
Sl'BD  1,  2,  s;.R 
JtiP  TODDLIK 


lA'C  1  ,  1 
JUP  OUTi'UT 

DLn;:i-;  i;ui'fer  poi:;t;:ps  to  buffi:rs 


OUTPTR:  liUKK 
CilKi’Tli:  liUlX; 
IKPTK:  LUKR 

M/^XPTi^;  DU;'I!+i33 


;If  VVQQ  does  nol  e;xi£t,  output 
;Katch  Buffor  contents  to  tcri'iinal 

;St.'irt  at  bc^innir.;;  of  Match  Buffer 

;Put  a  character  to  teruiiial  -  STTO 

;Load  location  of  last  buffer  character 
;]s  output  complete? 

;yf>s  -  send  curriapo  return  and  read 
:the  next  line  for  input 

;No  -  increment  buffer  pointer  and 
;  repeat 


;Pointer  to  next  output  character 
•.Pointer  to  buffer  start 
;Pointer  to  next  input  buffer  loc.'-ticn 
;PoinLer  to  t!ie  end  of  input  buffer 


0UT'’UT  CAKRIAGF.  RLTURi;  AS  LAST  CliARACTF.R  OF  A  WRITE 


TORDLlRlinA  0,  CR 
.SYSTM 
.PCHAR 


JMP 

C' 

•  KR 

LDA 

1 , 

MATSTR 

STA 

1. 

MATPTH 

JMP 

RDI.IKE 

;Load  carraige  return 

;Put  carraige  return  to  terminal 

;Res€t  pointers  to  beginning  of  lialch 
;Bu£fer  and  return  to  read  the 
;next  1 inc 


i 
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CONTI i:i;r'  to  (’omi'aki'.  KXFr.CTKU  RESi’o;;r.i:!-.  with  ini’ut 


LD.\ 

0,  MATP'iR 

;Look 

at  next  character  in 

INC 

0,  0 

;responst  buffer  and  match  but  for 

IKC 

2,  2 

DSX 

KSPSZ 

;Has 

the  size  of  tlu-  expected  I'osponse 

JMP 

CPRIAG 

;been 

exceeded?  1,'u  -  contii:ac  corgn-iring 

EDA 

]  ,  MA'i'STRT 

;  Y  e  s 

-  reset  buffer  pointers 

STA 

1  ,  MATPTR 

;  and 

return  to  read  the  next  1 ine 

JMP 

RDEINE 

EDA 

0,  MATPTi; 

;Do  the  same  for  second  response 

IKC 

o 

o 

IKC 

2,  2 

DSX 

RSPSZ 

JMP 

C  Pi!  2  AG 

EDA 

1,  MATSTRT 

STA 

I ,  MATPTR 

JMP 

KDEIHE 

CHECK  FOR  AN  IWXPECTED  ERROR  CORDITIO:; 


ERCIIK;  LF/i  1,  .ERDLE 
SURi-  I,  2,  SliR 
JF.P  Ol'TPliT-1 
EDA  1,  .ERUFT 
SURA  1,  2,  SZR 
JRP  Q  .EU 


;Eoad  expected  error  code  -  ERL'Ei' 

;Does  file  VVQQ  exist? 

;No  -  jui.ip  to  outi'Ut  to  I  f  I'iiiina  1 
;Load  another  expected  error 
;Is  tliis  channel  in  use? 

;Ko  -  state  unexpected  error  condition 


IF  FILE  VVQQ  EXISTS,  WRITE  ALE  TKPUT  TO  IT 


EDA  1 ,  MATSTRT 
WRTnrE:  STA  1,  IIATPTR 
EDA  1 ,  ORE 
EDA  0,  NATPTR 
MOVOL  0,  0 
.SYSTK 
.WKS  27 
Jt!P  .ER 


;Yes  -  write  input  buffer  toVVQO 

;Load  one  (1)  -  nuriber  of  bytes  to  v/ritc 

;Eoad  pointer  to  natch  buffer 

;Make  this  a  bytepointer  to  ripht  lyte 

;Write  right  bytC'  to  VVQQ 


EDA  ] ,  MATPTR 
EDA  2,  FMTRUSll 
SURA  ],  2,  SI!R 
JKP  TORDEIHE 
IKC  1  ,  1 
JMP  WRTOFL 


;Eook  at  pointer  to  ■.-'•■.tch  buffer 
;and  location  of  la.si  L-haractc  i 
;Is  buffer  writing  con'lete? 

;Yes  -  return  t.o  read  lu-xt  line 
;No  -  increment  point ir  and 
jwrite  next  character  to  VVQQ 


1  SI 


DrKii.K  vai;ai/i,i;s 


.E!;UFT; 

.KRDLi;:  rp.inj-: 

ONI:;:  1 

;  $TT0.1  n.'TFRRDPT  SKRVlCh  1:OUTJ!:k 


CIKA:  KKIC  TTOl 

Jt’.P  0,  3 


$TTil  INTFKia'PT  Si:KVIC1:  nOl'i'JF’F, 


IJKA;  STA  3,  USP 

STA  2,  S.'\Vi;2 
STA  1,  PAVn 
STA  0,  SAVT;ri 
MOVL  0,  0 
STA  0,  SAVEC 

DIAC  0,  TTIl 
LDA  3  ,  PiMSK 
ANU  3,  0 
STA  0,  Q  INPTR 

LDA  1,  INPTR 
IKC  1,  1 
LDA  2,  MAXPTR 
SliL',-  ],  2,  SNR 
JLP  CTIl'K 
STA  1,  INPTR 

RLTRN:  LDA  0,  SAV  i;C 

MOVk  0,  0 
LDA  0,  SAVFO 
LDA  1  ,  SAV  LI 
LDA  2,  SAVK2 
LDA  3,  USP 
JMP  0,  3 

C}IEK:  LDA  3,  OUTPTK 

LDA  2,  Cm.'PTR 
SIIILV  2,  3,  SNR 
JMP  PKOBl 

STA  2,  INPTR 
JMl’  RETKN 

Pl;OBl  :  HALT 


1  S2 


;  Ekt  ;  .  -  2]  ,  cli.'.;i.n('l  :n  u.'.t' 
;  ERDLL  “  12,  Lilt'  cic,  not. 


jldlc  dcvici:  $TTO]  p>,-;  rcMirn  to  PfXt 
jliiio  r.Ctcr  i.i,t pmija .  N'c;  i:i  f  to  i-av 
;t!i('  processor  statC',  as  it  is  nut 
;  chau;;cd 


Save  tlio  previops  |)roccssor  state  by 
savinp,  all  accui,  .I.a.tors  and  tl.o  carry 
bit.  USI'  is  User  Stack  Poii.icr 


jinput  character  fror.  $TTil 
;Str)p  parity  !)it  and 

; store  in  Bl'ER 

;Loa<j  pointer  to  nert  DUFR  location 
;  Iucrei;K  nt  it 

;Load  poii.tcr  to  last  buFfer  entry 
;ls  buffer  full?  Yes  -- 
;jump  to  see  if  buffer  has  been  used 
;No  -  SLort  new  pointer  value 

;Rer.tore  the  state  of  the  professor 


;Return  to  next  1  or  at  i  in  after  interm. 

;lf  outptr  is  still  a;  the  bi:;  iuiiins' 
;of  tlu  buffer  HUFF,  ; Fere  is  a 
;b>iffrr  overflu'./  I'otni'.jal  roijuirin;’ 
;tlK'  piocossor  to  b.iit.  Ol  herei  se  , 

; store  new  value  of  IN'P'  R  and 

; return 

;Not  a  r ecovera b  1  !.>  errcir  -  RTi  ’’ i 


koi'vim:  to  KiTi'Uk!:  to  'iiiH  ci.r  Ai;::oi:rAi,LY 


TTl;:  .syst:: 

.I'RTII  ;Abnori.:al  return  -  error 

JHT  Q  .l.K 

;  DEFi:;i;  ftouaoe  areas  aku  Turn'.us 


SAVi.O:  0 
SAVl'l  :  0 

SAVE  2  ;  0 

SAVl.C:  0 

H/'.TfiUKK ;  .  iiJ.E’  133.  ;f'atcli  buffer  has  91  do'cinal 

.  liLK  133.  ;  1  oaco  t  i  our. .  So  does  input  buff 


.INIJ  SYS  lb 


•jStoraj'G  area  for  arcunul  atur  0, 
;1,  2,  and  carr>  bit 
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AIR  FORCE  INST  OF  TECH  tiRt6HT«RATTERS0N  AFB  OH  SCNOO-^TC 
CONSTRtXTXON  OF  A  6ENERAL  RURROSC  COMMAND  LANDUAtC  FOR  USE 
SER  80  MO  6R1CSS  ^  ^ 

AFIT/6CS/EE/60S*18 


F/6  9/2 
IN  C— ETC' 

ML 


OTIC 


C - 

C - 

c 

C  THIS  IS  THE  CYBER  ACTION  FILE, 

C  +++++++  CREATED  7  AUGUST  1980;  REV  01  ++ 

C 

C  THE  FIRST  CONTROL  CARD  IMAGE  (l)  CONTAINS  EXPECTED  RESPONSES  FROM 
C  THE  CYBER  SYSTH. 

I  COliMAND-,., 

C 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  SENT  TO  THE  SYSTEM, 

C  CORRECT  INPUT  IS:  PUT,LFN,SFN,ID,SFPASSVJRD 

.  CACT ,  PUT ,  7A 1 ,  #2 ,  #3  , if  4 

V;S  COPYBF,  INPUT, ZQY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, ZQY 

WS  REQUEST, ZQZ,*PF 

WS  COPYBF, ZQY, ZQZ 

WS  CATALOG ,  ZQZ ,  #2  ,  ID=#3  ,  RP=999 ,  PW=if 4 

WS  RETURN, ZQZ, ZQY 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  RECEIVED  LOCALLY. 

C  CORRECT  INPUT  IS:  GET,SFN,ID,SFPASSWRD,LFN 

, CACT, GET, #1, #2, #3, #4 
WS  ATTACH , QZQ ,  #  1 ,  ID=i?2 ,  PU=#3 

RR 

WS  COPYSBF.QZQ, OUTPUT 

RC  XFER/A  VVQQ  #4/R 

WS  RETURN, QZQ 

END. 

C  THIS  COiniAND  PERMITS  SYSTEM  FILES  TO  BE  PRINTED  ON  SYSTEM  PRINTER. 

C  CORRECT  INPUT  IS:  SPRINT, SFN.SFPASSWRD 

.CACT, SPRINT,#! ,#2 
WS  ATTACH , ZXQ ,41, ?V=4 2 

WS  REQUEST, ZYQ,*Q 

WS  COPYSBF,ZXQ,ZYQ 

WS  REWIND, ZYQ 

WS  ROUTE , Z YQ , DC=PR , TID=BB , FID=NEO , ST=CSB 

WS  RETURN, ZXQ, ZYQ 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  PUNCHED  ON  SYSTEM  PUNCH. 

C  CORRECT  INPUT  IS:  SPUNCH,SFN,SFPASSWRD 

.CACT,SPUNCH,#1,#2 

WS  REQUEST, ZJQ,*Q 

WS  ATTACH, Z J J, #1 ,PW=#2 

WS  COPYSBF,ZJJ,ZJQ 

WS  REWIND, ZJQ 

WS  ROUTE ,  ZJQ ,  DC=PU ,  FID-NEO ,  TID-BB ,  ST*=CSB 

WS  RETURN, ZJQ,ZJJ 

END. 
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C  THIS  COlH'iAND  PKRMITS  SYSTEM  FILES  TO  BE  DELETED. 

C  CORRECT  INPUT  IS;  DELETE, SFN.SFPASSWRD 

.CACT, DELETE,#!, #2 

WS  PURGE, UZU, #1 ,PW=#2 

WS  RETURN, UZU 

END. 

C  THIS  COMMAND  PERMITS  DISPLAY  OF  SYSTEM  FILES  IN  USE  ( CREATED, ATTACHED ) . 

C  CORRECT  INPUT  IS:  FILES 

•CACT, FILES 

WS  FILES 

END. 

C  THIS  COMMAND  PERMITS  DISPLAY  OF  SYSTEM  PERMANENT  FILES  (AUDIT). 

C  CORRECT  INPUT  IS:  PFILES.USER  ID  (PROB  NUM) 

.CACT,PFILES,#1 

WS  AUDIT,  AI=P,ID=#-1 

END. 

C  THIS  COMMAND  PERMITS  USER  ACCESS  TO  THE  SYSTEM. 

C  CORRECT  INPUT  IS:  LOGON, USER  ID  (PROB  NUM), USER  PASSWRD 

.CACT, LOG ON,#!,# 2 

WL  Dia!  the  CDC  CYBER  telephone  number  (currently  5180  or  5159), 

WL  wait  for  the  tone,  and  then  place  the  telephone  headset 

WL  into  the  niodcm  receiver.  Now  strike  any  key 

WL  on  the  keyboard. 

RW 

WS  LOGIN,#!, #2, 777 

END. 

C  THIS  COIBtAND  TERMINATES  ACCESS  TO  THE  SYSTEM. 

C  CORRECT  INPUT  IS:  LOGOFF 

.CACT, LOGOFF 
WS  LOGOUT 

WL  The  CDC  CYBER  is  logged  out.  Enter  uparrow  L,  "''L",  to  return 

WL  to  the  local  NOVA/ECLIPSE  CLI. 

END. 
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C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  PRINTED  ON  SYSTEM  PRINTER. 

C  CORRECT  INPUT  IS:  LPRINT.LFN 

.CACT.LPRIKT,#! 

WS  REQUEST, XZX,*Q 

WS  COPYBF, INPUT, XZY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, XZY 

WS  COPYSBF,XZY,XZX 

WS  REWIND, XZX 

WS  ROUTE , XZX , DC=PR , FID=NEO , TID=BB , ST=CSB 

WS  RETURN, XZX, XZY 

END. 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  PUNCHED  ON  SYSTEM  PUNCH. 

C  CORRECT  INPUT  IS:  LPUNCH.LFN 

.CACT,LPUNCH,#1 

WS  REQUEST, JZX,*Q 

WS  COPYBF, INPUT, JZY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, JZY 

WS  COPYBF, JZY, JZX 

WS  REWIND, JZX 

WS  ROUTE , JZX, DC=PU , FID=NEO , TID=BB , ST=CSB 

WS  RETURN, JZX, JZY 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  EXECUTED  (BATCHED)  ON  SYSTEM. 

C  CORRECT  INPUT  IS:  SBATCH,SFN,SFPASSWRD, DISPOSITION, TERMINAL  ID 

.  CACT ,  SBATCH ,  #1 ,  #2 ,  #3 ,  #4 

WS  ATTACH , VQY , #1 , PW=#2 

WS  BATCH,VQY,#3,Y=#4 

WS  RETURN, VQY 

END. 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  EXECUTED  (BATCHED)  ON  SYSTEM. 

C  CORRECT  INPUT  IS:  LBATCH,LFN, DISPOSITION, TERMINAL  ID 

. CACT , LBATCH , #1 , #2 , #3 

WS  COPYBF, INPUT, VQX 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, VQX 

WS  BATCH,VQX,#2,Y=#3 

WS  RETURN, VQX 

END. 

FINISH. 
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c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

C' 

c- 


THIS  ACTION  FILE  I!AY  BE  EXPANDED  OR  CONTRACTED,  PROVIDED  ENTRIES  MEET 
THE  FOLLOWING  FORMAT  AND  CONTENT  GUIDELINES: 

A.  COMMAND  IDENTIFICATION  LINES  ARE  PRECEDED  BY  ".CACT"  . 

B.  THE  LAST  LINE  IN  EACH  DISTINCT  COMMAND  SEQUENCE  MUST  BE  "END."  , 

C.  THE  LAST  LINE  OF  THE  ENTIRE  FILE  MUST  BE  "FINISH.",  WITH  THE 
EXCEPTION  OF  COILMENT  LINES. 

D.  COMMENT  LINES  MAY  BE  PRECEDED  BY  ANY  CHARACTER  NOT  RESERVED 
AS  INDICATED  ABOVE  OR  BELOW.  FOR  CONVENIENCE,  "C"  HAS  BEEN 
CHOSEN. 

E.  THE  FIRST  TWO  COLUMNS  OF  EACH  LINE  SATISFY  CONTROL  FUNCTIONS; 

1)  "I  "  PRECEDES  THE  EXPECTED  RESPONSES  FROM  THE  SYSTEM. 

THEY  ARE  USED  TO  INITIALIZE  THE  EXPECTED  RESPONSE  ARRAYS. 

2)  "WS"  PRECEDES  INFORMATION  TO  BE  WRITTEN  TO  THE  SYSTEM. 

3)  "WL"  PRECEDES  INFORMATION  TO  BE  WRITTEN  TO  THE  LOCAL  TERM. 
A)  "RW"  PRECEDES  BLANK  LIME;  INDICATES  A  BACK-TO-BACK  LOCAL 

TERM  READ  FOLLOWED  BY  A  SYSTEM  WRITE. 

5)  "WC"  PRECEDES  CALL  TO  COPY  A  LOCAL  FILE  AND  WRITE  IT 
TO  THE  SYSTEM. 

6)  "RC"  PRECEDES  CALL  TO  COPY  A  LOCAL  FILE  THAT  HAS  BEEN 
READ  FROM  THE  SYSTEM. 

7)  "RR"  PRECEDES  BLANK  LINE;  INDICATES  THAT  AN  "RC"  CONTROL 
WILL  FOLLOW  AND  MAKES  READY  A  LOCAL  FILE  FOR  THE  READ. 

8)  SEE  A  THROUGH  D  ABOVE  FOR  OTHER  CONTROL  FUNCTIONS. 

F.  ALL  LINES  (CONTROL  CHARACTERS)  lOJST  BEGIN  IN  COLUMN  ONE  (1); 

ALL  INFORMATION  IN  LINES  OTHER  THAN  THOSE  DESCRIBED  IN  A  THROUGH  D 
ABOVE  MUST  CONTINUE  IN  OR  AFTER  COLUMN  NIKE  (9),  EXCEPT  FOR  COMMENT 
LINES.  (TABS  CANNOT  BE  USED  ANYWHERE  IN  THE  ACTION  FILE,  EXCEPT 
IN  COMMENT  LINES  AFTER  THEIR  CONTROL  CHARACTERS.) 
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o  o  o 


C  THIS  IS  THE  DEC  ACTION  FILE.  THERE  ARE  NO  ENTRIES 

C  AS  OF  15  JULY  1980. 

C 

I 

FINISH. 


C  THIS  IS  THE  VAX  ACTION  FILE.  THERE  ARE  NO  ENTRIES 

C  AS  OF  15  JULY  1980. 

C 

I 

FINISH. 


THIS  IS  MY  OWN  ACTION  FILE.  THERE  ARE  NO  ENTRIES 
AS  OF  15  JULY  1980. 


I 

FINISH. 
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20.  ABSTRACT  (Continue  on  reverae  aide  If  neceaaery  end  Identify  by  block  number) 

'^o  computer  programs  were  developed  and  implemented  to  enable 
intercommunication  between  a  Data  General  NOVA/ECLIPSE  computer  system 
and  another  modem  linked  computer  system.  One  program,  called  TTERMOP, 
allows  a  user  to  sit  at  a  NOVA  terminal  and  interact  with  a 
connected  system  in  a  transparent  mode.  The  other  program,  called  MONITOR, 
is  a  command  language  interpreter  that  examines  and  executes  instructions 
contained  within  an  action  file.  An  action  file,  consisting  of  instruction 
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strings  and  associated  control  parameters,  is  designed  to  be  dependent 
upon  a  connected  system  with  regard  to  contents,  yet  independent  of  such 
connected  system  with  regard  to  structure  and  format.  The  interpreter  is 
written  in  FORTRAN  IV  with  FORTRAN  and  assembly  language  modules. 

Actual  implementation  of  the  programs  is  accomplished  between  the 
NOVA/ECLIPSE  and  the  Aeronautical  Systems  Division  Control  Data  CYBER 
computer  system.  ASCII  data  files  between  20  and  35,000  bytes  have 
been  transferred  between  the  two  interconnected  systems, 
each  transfer  initiated  by  a  single  string  command 
acceptable  to  the  interpreter  and  compatible  with  a  tailored 
action  file  for  the  CYBER  system.  The  programs  were  designed  to  be 
flexible  enough  for  use  with  several  different  connected  systems,  and 

general  enough  to  be  hosted  on  a  system  other  than  the  NOVA/ ECLIPSE.  > _ 

However,  no  attempt  is  made  to  implement  the  programs  outside  of  the 
NOVA/ECUPSE  -  CYBER  environment. 
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